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Strategies  to  Mitigate  Obsolescence  in  Defense 
Systems  Using  Commercial  Components 
(RTO  MP-072  /  SCI-084) 

Executive  Summary 

With  the  rapid  movement  towards  Commercial  Off  The  Shelf  (COTS)  solutions  within  the  US  DoD 
procurement  agencies  and  the  simultaneous  rapid  consolidation  of  the  US  defense  industrial  base, 
obsolescence  management  and  what  has  been  referred  to  as  Diminishing  Manufacturing  Sources  and 
Material  Shortages  (DMSMS)  is  of  great  concern  to  both  NATO  governments  and  the  defense/ 
aerospace  industry.  Both  governments  and  the  defense  industry  face  the  dilemma  of  responding  to 
requests  for  out-of-production  items,  primarily  from  within  the  semiconductor  industry.  The 
discontinuance  rate  of  microelectronics  parts  has  steadily  increased.  Many  recent  acquisition  reform 
initiatives  have  shaken  the  foundation  of  the  defense  electronics  industry  and  the  associated 
government  organizational  cultures.  Solutions  to  ease  the  way  forward  are  needed. 

The  symposium  outlined  current  problems  of  and  solutions  to  the  issue  of  obsolescence  for  the  entire 
defense  system  community.  It  addressed  questions  related  to  the  problem  of  parts  obsolescence, 
diminishing  manufacturing  sources  and  material  shortages.  It  also  covered  the  actual  status  and 
experience  in  the  application  of  COTS  in  defense  electronic  systems  and  reviewed  associated  benefits 
and  drawbacks.  Management  tools  and  methodologies  to  cope  with  the  risk  of  obsolescence  were 
discussed.  This  included  new  design  concepts  and  system  architectures  to  allow  advanced  technology 
insertion  during  the  system  life  cycle,  thereby  combating  obsolescence.  Papers  were  presented  during 
the  following  sessions: 

-  Status  and  Experience  with  COTS  Technology  in  Defense  Electronics  Systems 

-  Obsolescence  Management  and  Tools 

-  New  Design  Concepts  and  Architectures  to  Combat  Obsolescence 

-  Strategies  and  Initiatives  for  Eife  Cycle  Management 

Many  excellent  papers  were  presented  at  this  symposium  providing  a  good  analysis  of  the  problems  of 
and  recommendations  on  how  to  cope  with  obsolescence  challenges  in  NATO  defense  systems.  Unless 
the  problem  of  obsolescence  and  diminishing  manufacturing  sources  is  widely  accepted  by 
governments,  procurement  or  organisations  and  industries,  our  programs  will  be  severely  impacted.  It 
is  necessary  to  build  partnerships  to  reduce  diminishing  manufacturing  sources.  We  have  to  confront 
obsolescence  in  a  proactive  manner  and  plan  new  technology  insertions.  Solutions  must  be  orderly, 
planned  and  budgeted  for.  What  is  needed  is  total  weapon  systems  life  cycle  management.  Only  with 
this  NATO  will  keep  its  systems  current,  operational  and  available. 
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Strategies  visant  a  attenuer  1 ’obsolescence  des 
systemes  par  I’emploi  de  composants  du  commerce 

(RTO  MP-072  /  SCI-084) 


Synthese 

Suite  a  1’ adoption  rapide  de  produits  du  commerce  (  COTS  )  par  la  direction  des  appro visionnements 
du  ministere  de  la  defense  US,  qui  s’est  produite  en  meme  temps  que  la  consolidation  rapide  de  la  base 
industrielle  de  defense  US,  la  gestion  de  Tobsolescence,  et  ce  qui  a  etc  appelee  -  Les  sources  de 
fabrication  en  diminution  et  les  penuries  de  materiaux  (DSMS)  -  sont  devenus  un  sujet  de 
preoccupation  majeur  pour  les  gouvernements  des  pays  membres  de  TOT  AN,  ainsi  que  pour  les 
industries  de  la  defense/aerospatiales.  Les  gouvernements  et  les  industries  de  la  defense  sont 
confrontes  par  le  dilemme  de  savoir  comment  repondre  a  des  demandes,  emanant  principalement  de 
Tindustrie  des  semiconducteurs,  relatives  a  des  elements  qui  ne  sont  plus  fabriques.  Le  rythme 
d’ interruption  de  fabrication  dans  Tindustrie  de  la  microelectronique  s’est  accelere  de  faqon  continue. 
La  reforme  de  T appro visionnement  a  ebranle  jusque  dans  leurs  fondements  et  Tindustrie  de 
Telectronique  de  defense  et  les  structures  gouvernementales  dans  ce  secteur.  II  est,  par  consequent, 
indispensable  de  trouver  des  solutions  permettant  de  definir  la  voie  a  suivre. 

Le  symposium  a  fait  le  point  des  problemes  actuels  et  des  solutions  envisagees  pour  resoudre  la 
question  de  Tobsolescence  par  les  specialistes  des  systemes  de  defense  dans  tons  les  pays  membres  de 
TOTAN.  La  reunion  a  examine  des  questions  relatives  aux  problemes  de  Tobsolescence  des  pieces,  de 
la  diminution  des  sources  de  fabrication  et  des  penuries  de  materiaux.  Elle  a  evoque  la  situation 
actuelle  et  T  experience  acquise  en  matiere  de  mise  en  oeuvre  de  COTS  dans  les  systemes  electroniques 
de  defense  et  a  fait  allusion  aux  avantages  et  inconvenients  y  associes.  Des  outils  et  des  methodologies 
de  gestion  permettant  de  faire  face  a  la  menace  de  Tobsolescence  ont  ete  discutes.  Les  sujets  discutes 
ont  compris  les  nouveaux  concepts  et  architectures  de  systeme  permettant  T  insertion  de  technologies 
avancees  pendant  le  cycle  de  vie  du  systeme,  pour  combattre  Tobsolescence.  Les  communications  ont 
ete  presentees  lors  des  sessions  suivantes  : 

-  Situation  actuelle  et  experience  dans  le  domaine  de  la  mise  en  oeuvre  des  technologies  COTS  dans 
les  systemes  electroniques  de  defense 

-  Gestion  de  Tobsolescence  et  outils 

-  Nouvelles  architectures  et  nouveaux  concepts  pour  combattre  Tobsolescence 

-  Strategies  et  initiatives  pour  la  gestion  du  cycle  de  vie 

Le  symposium  a  presente  des  communications  d’un  tres  haut  niveau,  offrant  une  bonne  analyse  des 
problemes  rencontres,  ainsi  que  des  recommandations  concernant  les  moyens  de  faire  face  aux  defis  de 
Tobsolescence  des  systemes  de  defense  de  TOTAN.  Si  les  problemes  de  Tobsolescence  et  les  sources 
de  fabrication  en  diminution  ne  sont  pas  pris  en  compte  par  les  gouvernements,  les  organisations 
d’ appro  visionnement  et  Tindustrie,  ils  auront  un  impact  considerable  sur  les  programmes  de  defense.  II 
est  necessaire  de  construire  des  partenariats,  afin  d’endiguer  la  diminution  des  sources  de  fabrication. 
Nous  devrons  faire  face  a  Tobsolescence  et  prevoir  Tinsertion  des  nouvelles  technologies.  II  s’agit  de 
la  prevision  methodique  et  la  budgetisation  des  solutions.  II  faut  mettre  en  place  des  systemes  de 
gestion  du  cycle  de  vie  des  systemes  d’armes.  Seule  cette  mesure  permettra  a  TOTAN  de  disposer  de 
systemes  de  pointe  totalement  operationnels. 
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Commercial  Of  The  Shelf  (COTS)  technology  in  military  systems  was  initiated  hy  the  US  Federal  Acquisition 
Reform  Act  as  early  as  1994.  While  many  military  programs  still  require  custom  engineering,  commercial  of  the 
shelf  technology  is  clearly  posed  to  dominate  the  future  of  defense  electronic  systems. 

With  the  rapid  movement  towards  COTS  within  the  US  DoD  procurement  and  the  simultaneous  rapid 
consolidation  of  the  US  defense  industrial  base,  obsolescence  management  or  what  is  referred  to  as  - 
Diminishing  Manufacturing  Sources  and  Material  Shortages  (DMSMS)  -  is  of  great  concern  to  both  NATO 
Governments  and  the  Defense/Aerospace  Industry.  Government  and  defense  industry  face  the  dilemma  of 
responding  to  out-of-production  items,  primarily  from  the  semiconductor  industry.  The  rate  of  microelectronics 
discontinuance  has  steadily  increased.  The  acquisition  reform  has  shaken  the  foundation  of  defense  electronics 
industry  and  government  organizational  cultures.  Solutions  to  ease  the  way  forward  are  mandatory. 

New  strategies  for  obsolescence  management  including  open  architecture,  functional  partitioning  and  technology 
insertion  have  to  be  addressed  during  system  engineering,  detailed  design,  production  and  product  support. 


Theme 


La  mise  en  oeuvre  des  technologies  des  composants  du  commerce  (COTS)  dans  les  systemes  militaires  a  ete 
instauree  par  la  loi  reformant  les  acquisitions  federates  US  des  1994.  Si  bon  nombre  des  programmes  militaires 
continuent  de  prevoir  des  ensembles  fabriques  a  la  demande,  les  technologies  des  composants  du  commerce 
semblent  etre  destinees  a  s’imposer  pour  la  fabrication  des  futurs  systemes  electroniques  de  defense. 

Suite  a  T adoption  rapide  de  COTS  par  la  direction  des  approvisionnements  du  ministere  de  la  defense  US,  qui 
s’est  produite  en  meme  temps  que  la  consolidation  rapide  de  la  base  industrielle  de  defense  US,  la  gestion  de 
Tobsolescence,  communement  appelee  -  reduction  des  sources  de  fabrication  et  penuries  de  materiaux  (DSMS) 
-  est  devenue  un  sujet  de  preoccupation  majeur  pour  les  gouvernements  des  pays  membres  de  TOTAN,  ainsi  que 
pour  les  industries  de  la  defense  et  aerospatiales.  Les  gouvernements  et  les  industries  de  la  defense  sont 
confrontes  au  dilemme  de  savoir  comment  repondre  a  des  demandes,  emanant  principalement  de  T  Industrie  des 
semiconducteurs,  relatives  a  des  elements  qui  ne  sont  plus  fabriques.  Le  rythme  d’ interruption  de  fabrication 
dans  Tindustrie  de  la  microelectronique  s’est  accelere.  La  reforme  de  T appro visionnement  a  ebranle  jusque  dans 
leurs  fondements  et  Tindustrie  de  Telectronique  de  defense  et  les  structures  gouvemementales  dans  ce  secteur.  II 
est,  par  consequent,  indispensable  de  trouver  des  solutions  permettant  de  definir  la  voie  a  suivre. 

De  nouvelles  strategies  de  gestion  de  Tobsolescence,  y  compris  Tarchitecture  ouverte,  le  decoupage  fonctionnel 
et  Tinsertion  des  technologies,  doivent  etre  examinees  lors  des  phases  de  Tingenierie  des  systemes,  du  projet 
detaille,  de  la  production  et  du  support  technique. 
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INTRODUCTION 

Background 

Since  1997  the  Research  and  Technology  Organisation 
(RTO)  has  been  NATO’s  single  focus  for  defence 
research  and  information  interchange.  The  System  and 
Concepts  Integration  (SCI)  panel  is  one  of  six  panels 
that  cover  the  scientific  and  technical  disciplines  that 
bear  upon  defence  issues.  The  SCI  panel  deals  with 
advanced  system  concepts,  integration,  engineering 
techniques  and  technologies  applicable  to  all  platforms 
and  operating  environments,  concentrating  on  mid  to 
long  term  system  level  operational  needs. 

During  the  period  of  operation  of  the  RTO  and  the  SCI 
panel,  very  significant  changes  have  taken  place  in  the 
area  of  defence  procurement.  The  ever  increasing  cost 
of  acquiring  military  hardware  and  software,  together 
with  major  shifts  in  the  electronics  marketplace, 
prompted  Defense  Acquisition  Reform  in  the  USA  as 
an  attempt  to  leverage  the  defense  dollar  through 
utilization  of  commercial  technology  advances. 

The  decision,  prompted  by  the  now  famous  “Perry 
Memorandum”  of  1994,  to  move  towards  performance 
based  specifications  led  to  the  virtual  abandonment  of 
the  MIL-STD  and  MIL-SPEC  system  that  had 
underpinned  military  procurement  for  several  decades. 
At  the  same  time  the  market  in  semiconductors  was 
increasingly  being  driven  towards  commercial 
telecommunications  and  computing  needs,  resulting  in 
a  reducing  number  of  types  and  sources  of  military 
components.  This  effect  has  also  been  felt,  although  to 
a  lesser  extent,  in  the  material  supply  and  non¬ 
semiconductor  component  markets.  In  combination 
these  effects  produce  an  ongoing  obsolescence 
problem  for  legacy,  or  fielded,  defence  systems 
worldwide. 

The  impact  of  Diminishing  Manufacturing  Sources  and 
Material  Shortages  (DMSMS)  can  vary  from  the 
merely  irritating  to  the  showstopper.  It  is  of  grave 
concern  to  the  NATO  governments  and  the  Defence 
and  Aerospace  industry,  and  the  rate  of  discontinuance 
of  part  availability  is  steadily  increasing.  Many 
programs  such  as  the  F22  stealth  fighter,  AW  ACS, 
Tornado  and  Eurofighter  are  suffering  from 
obsolescence.  Concurrently  with  this  increasing  rate  of 


military  part  obsolescence  has  come  a  progressive 
acceptance  of  the  use  of  Commercial  Off  The  Shelf 
(COTS)  components,  assemblies  and  systems  in  the 
defence  arena.  It  is  against  this  background  that  the 
SCI  panel  initiated  this  symposium. 

Theme 

The  reform  of  the  acquisition  process  in  the  Defence 
Industry  has  radically  altered  the  culture  of  the 
Defence  Electronics  Industry  and  Governmental 
Organisations.  The  steadily  increasing  rate  of 
microelectronics  discontinuance  demands  improved 
obsolescence  management  be  employed.  The 
migration  to  the  use  of  COTS  in  defence  systems  has 
been  viewed  as  a  possible  solution  to  current 
obsolescence.  This  symposium  was  convened  to 
review  the  actual  problems  and  solutions  to  the  issue  of 
obsolescence  as  experienced  by  the  entire  defence 
community.  It  sought  to  examine  new  strategies  for 
the  management  of  obsolescence  such  as  the  use  of 
open  architectures,  adopting  a  systems  engineering 
approach,  and  employing  planned  technology 
refresh/technology  insertion  throughout  the  equipment 
or  system  life  cycle,  from  initial  design  to  product 
support. 

Purpose  and  Scope  of  the  Symposium 

The  purpose  of  the  symposium  was  to  address  the 
burning  questions  related  to  the  problems  of  parts 
obsolescence  and  diminishing  manufacturing  sources 
and  material  shortages,  to  review  the  management 
tools  and  techniques  employed  in  dealing  with 
obsolescence,  and  to  examine  the  current  status  and 
experience  in  the  application  of  COTS  in  defence 
electronics  systems.  The  meeting  would  also  examine 
new  design  concepts  and  system  architectures  that 
allow  the  insertion  of  advanced  technology  during  the 
system  lifecycle  and  thus  mitigating  obsolescence. 

The  declared  scope  of  the  Symposium  is  best 
summarised  in  the  four  sessions  by  which  the  meeting 
was  organised. 

Session  I  -  Status  and  Experience  with  COTS 
Technology  in  Defense  Electronic  Systems. 

To  present  current  defence  industry  experience  in  the 
application  of  COTS  technologies  and  components  to 
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defence  electronics  systems,  highlighting  the  successes 
and  difficulties  encountered  and  the  lessons  learnt. 

Session  II  -  Obsolescence  Management  and  Tools. 

To  discuss  the  variety  of  methodologies  and  tools 
available  today  and  proposed  for  the  future,  which 
facilitate  the  proactive  management  of  obsolescence. 

Session  III  -  New  Design  Concepts  and  Architectures 
to  combat  obsolescence. 

To  address  the  system  engineering  approach  to 
obsolescence  mitigation  through  the  use  of  design 
concepts  and  architectures  that  are  effectively 
technology  transparent  and  as  such  are  significantly 
immune  from  the  effects  of  component  obsolescence. 

Session  IV  - 

To  address  the  strategic  viewpoint  in  approaches  to 
obsolescence  management,  seeking  to  adopt  an 
holistic,  long-term  perspective. 

EVALUATION 

General 

The  subject  matter  of  the  symposium  is  such  a 
widespread  and  debilitating  phenomenon  that  the  need 
for  the  RTO  to  organise  such  an  event  is  indisputable. 

Every  defence  force  in  NATO  is  suffering  an 
increasing  rate  of  attack  on  their  ability  to  field  current, 
legacy  systems  due  to  part  obsolescence.  The  same 
issue  is  also  hampering  procurement  of  follow-on  and 
new  systems  and  equipment. 

Somewhat  perversely,  the  rapidity  of  part 
unavailability  is  less  for  legacy  systems  designed  in  the 
1970’s  and  1980’s  than  in  their  replacements  currently 
being  deployed  or  under  development.  Modem  fighter 
aircraft  such  as  Eurofighter  Typhoon,  find  themselves 
at  the  front  edge  of  the  curve  through  use  of  advanced 
microelectronic  devices,  which  are  themselves  out  of 
production  before  the  aircraft  has  made  its  first 
production  deliveries. 

The  spectmm  of  obsolescence  effects  is  broad.  It 
encompasses  not  only  advanced  microelectronics,  but 
also  materials  used  in  legacy  systems  for  which  there  is 
no  longer  a  MIL-Spec.  nor  a  supplier;  basic  electrical 
piece  parts  for  which  the  market  has  dwindled  to  the 
re-supply  of  military  hardware;  software  which  is  no 
longer  compatible,  and  is  neither  supported  nor 
modifiable  to  meet  today’s  requirements.  It  is  due  to 
the  incredible  growth  in  commercial  microelectronics 
over  the  past  twenty  years,  and  the  consequent 
abandonment  of  the  military  market  by  most  of  the 
major  integrated  circuit  manufacturers  during  the  same 
period,  that  the  debate  on  obsolescence  in  defence 
systems  tends  to  focus  on  the  effects  of 


microelectronics  obsolescence  on  equipment  and 
systems,  almost  to  the  exclusion  of  all  else.  Modem 
weapons  platforms  comprise  a  number  of  systems; 
those  systems  are  made  up  of  several  equipments,  and 
it  is  at  the  equipment  level  that  obsolescence  has  its 
most  immediate  impact.  It  is  not  unnatural  therefore 
that  the  Symposium  has  tended  to  focus  on  the  trials 
and  tribulations  of  equipment  suppliers  seeking 
solutions  that  are  often  not  within  their  gift  to 
implement,  but  instead  lie  with  the  prime  contractor 
and  the  government  procuring  agency. 

Given  that,  the  Symposium  was  still  slightly 
unbalanced,  in  that  there  were  precious  few  papers 
citing  actual  experience  of  using  COTS.  Overall 
insufficient  distinction  was  made  between  the  separate 
problems  of  maintaining  legacy  systems,  and 
minimising  the  effects  of  obsolescence  in  new  build 
systems.  If  obsolescence  is  not  designed  out,  then  it  is 
designed  in. 

Only  one  paper  (paper  1)  addressed  itself  directly  to 
the  fundamental  question  posed  by  the  title  of  the 
symposium,  i.e.  is  the  use  of  commercial  components 
in  defence  equipment  a  good  strategy  for  mitigation  of 
obsolescence.  All  of  the  other  papers  were  concerned 
with  individual  approaches  to  specific  problem  areas 
and  not  to  the  success  or  otherwise  of  the  strategy 
overall.  This  may  be  a  further  reflection  of  the 
opinion,  stated  earlier,  that  the  effects,  and 
consequently  the  problem  solving  efforts,  are 
concentrated  in  the  equipment  supply  echelon  of  the 
defence  procurement  hierarchy.  Strategy  formulation 
tends  to  be  the  preserve,  and  concern,  of  the  weapons 
platform  system  authority  and  their  customers,  the 
national  defence  procurement  agencies,  who  have 
tended  to  flow  down  rigid  requirements  specifications 
that  leave  little  room  for  manoeuver. 

This  technical  evaluation  of  the  Symposium  deals  with 
the  papers  as  presented  in  the  context  of  their  sessions, 
and  discusses  the  arguments  presented  therein.  The 
overall  outcome  of  the  symposium  is  set  in  a  broader 
context  in  the  conclusions. 

Keynote  Address 

Mr.  Ted  Glum,  Director  of  the  Defense 
Microelectronics  Activity  (DMEA)  located  at 
McLellan  AFB  in  California,  gave  the  keynote  address. 
Refreshingly,  Mr.  Glum’s  presentation  was  directly 
relevant  to  the  subject  matter  of  the  Symposium  and 
indeed  offered  one  solution  to  the  problems  of 
obsolescent  parts,  especially  in  the  case  of  legacy  or 
fielded  systems. 

His  opening  remarks  painted  the  landscape  that  forms 
the  backdrop  against  which  all  our  current  efforts  to 
deal  with  obsolescence  are  set. 
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•  Increased  reliance  on  microelectronics  in  our 
systems,  the  supply  of  which  is  increasingly 
unstable. 

•  Incompatibility  of  weapon  system  lifecycles  of 
20/30  years,  with  the  current  18  months  mean  time 
between  IC  technology  iterations. 

•  The  entire  Defense  industry  share  of  the  global 
microelectronics  market  is  now  only  about  0.3%, 
so  our  influence  on  the  component  manufacturers 
is  minimal. 

•  Obsolescence  is  a  business  decision,  made  by 
these  component  manufacturers. 

He  also  alluded  to  the  familiar  problem  arising  from 
project  organisation  structures,  which  faced  with  the 
common  problem  of  obsolescence,  devise  individual 
solutions  for  their  project  area,  leading  to  unnecessarily 
high  operation  and  support  costs.  It  was  to  combat  this 
that  the  US  DOD  invested  in  the  creation  of  DMEA 
and  gave  them  the  mission  to  provide  microelectronics 
technology  solutions.  Reactive  strategies  used 
heretofore  represent  the  antithesis  of  modem  business 
philosophy  and  tend  to  produce  technical  solutions  not 
business  solutions. 

DMEA  promotes  proactive  strategy,  recognising  that 
obsolescence  is  a  business  decision  and  that  technical 
solutions  must  have  a  valid  business  case,  and  by 
providing  common  solutions  to  common  problems 
across  the  boundaries  of  projects,  DMEA’s 
engineering  capabilities  enable  a  range  of  tailored 
solutions  to  be  offered. 

The  US  government’s  investment  in  ‘Flexible  Foundry 
Technology’,  together  with  government  held  process 
licences  and  agreements  on  terminal  transfer,  enables 
DMEA  to  provide  prototype/low  volume  manufacture 
and  supply  of  obsolete  or  specialist  parts,  including  5 
volt  devices.  The  effectiveness  of  this  approach/setup 
has  already  been  demonstrated  in  providing  solutions 
to  F-22,  F-16  and  B-2  obsolescence  issues.  The  DOD 
are  effectively  proposing  a  series  of  initiatives  through 
DMEA,  including  industry  partnership,  the  unique 
flexible  foundry  and  leveraged  technical  solutions  with 
business  models,  as  their  answer  to  the  challenge  of 
minimal  market  leverage  and  increased  reliance  on 
critical  technologies. 

Session  I  -  Status  and  experience  with  COTS 
technology  in  Defense  Electronic  Systems. 

The  late  withdrawal  of  paper  3,  together  with  the 
earlier  loss  of  paper  4,  left  only  four  papers  to  be 
presented  in  this  opening  session. 

The  presentations  covered  many  different  aspects  of 
the  use  of  COTS  in  Defence  Systems,  from  detailed 
environmental  considerations  of  fast  jet  use  to  ground 
systems  implementations  using  COTS  systems  and 
software.  The  titular  theme  of  the  symposium  was 
addressed  in  paper  1,  which  reviewed  the  key 
difficulties  for  an  Avionics  supplier  confronting  the 
problems  of  obsolescence  and  considering  the  use  of 


COTS  components.  There  is  an  incompatibility 
between  the  lifecycles  of  weapons  platforms  and 
microelectronic  components,  and  this  was  pointed  out. 
Also,  Diminishing  Manufacturing  Sources  (DMS) 
result  in  an  inability  to  procure  military  components 
for  long  term  product  support.  Therefore  the  use  of 
COTS  parts  in  military  systems  has  become  a 
necessity.  However,  it  was  argued  that  the  use  of 
COTS  to  mitigate  obsolescence  is  a  contradiction  in 
itself  COTS  are  more  part  of  the  problem  than  part  of 
the  solution,  and  provide  an  additional  challenge  to 
proactive  obsolescence  management,  which  is  an 
essential  part  of  tomorrow’s  programmes  planning.  A 
major  obstacle  to  the  use  of  COTS  today  is  the 
continuation  of  rigid  requirements  still  being  flowed 
down  to  equipment  suppliers  in  RFQ’s.  The  theme  of 
incompatible  product  vs.  part  lifecycles  was  refrained 
in  the  second  paper  (paper  2),  which  also  introduced 
further  key  themes  of  the  symposium  -  open 
architecture,  modularity,  and  planned  technology 
insertion  strategies.  The  speaker  suggests  we  consider 
COTS  procurement  as  a  process  that  must  be  adopted 
to  achieve  the  true  benefits  of  COTS.  Obsolescence 
Management  is  part  of  a  lifecycle  management 
approach  that  must  be  tailored  to  suit  the  needs  of  the 
individual  product  and  programme.  The  design  may 
be  frozen  at  entry  to  production  phase,  with  Lifetime 
buys  to  cover  foreseeable  product  maintenance  and 
support  needs,  or  else  involve  a  combination  of 
modular  open  architecture  design,  with  planned 
technology  insertion.  For  this  approach  to  be  effective 
it  requires  a  supply  chain  partnership  to  mitigate  the 
effects  of  Obsolescence,  the  causes  of  which  are 
outwith  our  direct  control. 

One  of  the  major  impediments  to  the  wider  use  of 
COTS  devices  in  military  avionics  is  the 
incompatibility  of  environmental  requirements 
specified  for  the  parts  and  for  the  equipment.  Two 
solutions  exist  -  ‘uprate’  the  individual  components  to 
meet  the  operational  environment,  or  ‘derate’  the 
operational  environment  to  suit  the  components.  The 
third  paper  (paper  5)  in  this  session  addressed  this 
latter  approach,  specifically  addressing  the  methods 
that  can  be  used  to  improve  the  environmental  control 
system  on  a  fast  jet  fighter.  These  include  a  new 
approach  to  Environmental  Control  System  (ECS) 
design  -  existing  ECS  designs  are  based  upon  fifty  year 
old  concepts,  improved  EMC  design  and  active 
damping  to  reduce  the  effects  of  vibration.  In  adopting 
this  top-down  approach,  the  prime  contractor  provides 
one  common  solution  for  all  his  avionics  suppliers, 
thus  preventing  the  proliferation  of  individual,  unique 
solutions  that  will  be  more  expensive  overall,  and  less 
supportable  at  system  level.  This  perspective  echoes 
one  of  the  themes  of  DMEA  in  the  keynote  address. 
Overall  the  life  cycle  cost  of  using  ruggedised, 
specialist  designed  avionics  will  probably  exceed  the 
cost  of  adapting  the  aircraft  environment  to  suit  non- 
ruggedised  COTS  equipment.  However,  such  changes 
to  the  airframe  environment  must  always  bear  in  mind 
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the  performance,  power,  weight  and  offensive  load 
carrying  characteristics  required  to  complete  the 
aircraft  mission. 

The  final  paper  of  the  session  (paper  6)  demonstrated 
that,  when  constrained  by  very  tight  financial  and 
timescale  limits,  innovative  COTS  based  solutions 
could  be  provided  to  update  an  obsolete  system.  The 
Hungarian  Air  Defence  System  was  updated  to  include 
an  Air  Sovereignty  Operations  Centre  (ASOC)  with 
digital  data  links  to  the  civil  and  military  radar’s 
operating  in  the  country.  This  was  achieved  using  80% 
commercial  components,  systems  &  software.  In  two 
years  of  operation  the  system  reliability  is  limited  by 
the  reliability  of  the  legacy  radar  equipment.  Use  of 
COTS  may  therefore  be  a  valid  strategy  for  providing  a 
swift  and  low  cost  upgrade  to  obsolete  ground  sector 
equipment  in  the  short  to  medium  term. 

Session  II  -  Obsolescence  Management  and  Tools. 

Eight  papers  were  presented  in  this  session,  including  a 
late  addition.  The  new  themes  in  this  session  were  the 
adoption  of  a  system  engineering  approach,  the 
benefits  from  the  use  of  information  technology  to 
provide  timely  notification  of  obsolescence  and  to 
manage  it,  and  the  use  of  software  tools  to  create 
virtual  hardware  definitions  which  are  therefore 
technology  transparent. 

The  first  paper  (paper  7)  provided  a  comprehensive 
description  of  a  system  engineering  assessment  model 
for  use  as  a  tool  to  cope  with  the  risks  associated  with 
the  use  of  COTS  in  the  system  life  cycle.  This 
methodology  was  developed  for  use  in  the  US  naval  air 
systems  command  to  assess  the  most  cost  effective 
COTS  equipment  based  on  affordability,  reliability, 
mission  requirements  and  ability  to  accommodate 
future  modification  and  update.  Beginning  with  the 
mission  need,  a  requirements  analysis,  equipment 
classification  and  market  research  are  carried  out, 
followed  by  an  alternatives  risk  assessment  and  risk 
mitigation,  including  validation.  The  conclusion  of  the 
process  is  an  input  to  procurement.  This  risk-based 
systems  engineering  assessment  model  provides  a 
common  framework  for  making  COTS  technology 
decisions  by  assessing  the  relative  risk  of  each  COTS 
alternative.  It  also  provides  assistance  in  determining 
the  appropriate  degree  of  validation  required  to  verify 
that  a  COTS  alternative  can  be  transferred  to  the 
military  environment. 

The  second  paper  (paper  8)  dealt  with  the  more 
specific  problem  of  preserving  the  longevity  of  Asics’s 
and  associated  devices  such  as  PLD’s  and  FPGA’s. 
The  approach  adopted  was  to  form  an  industrial 
consortium  called  COCISPER  to  pool  experience  and 
methods,  and  to  develop  an  operational  guide  that 
outlines  the  methodologies  to  be  employed  in  the 
design  and  manufacture  of  Asics’s.  The  guide  has 
been  made  available  to  a  wider  audience  via  the 
Internet,  and  in  scope  covers  the  entire  process  from 
technical  requirements  specification  to  project  and  risk 


management  and  durability  assurance.  This  on  the 
whole  represents  an  obsolescence  strategy  that  is  a 
combination  of  life  time  buy,  grouping  together  to 
create  a  sizeable  market,  source  control,  and 
technology  transparency  through  the  use  of  VHDL 
system  definition  &  description. 

The  cost  impact  of  software  changes  consequent  upon 
a  hardware  change  is  recognised  in  the  next  paper 
(paper  9).  Development  of  major  equipment  such  as 
radar  can  be  very  costly  in  time  and  money.  The 
approach  proposed  here  was  to  make  extensive  use  of 
simulation  to  design  a  virtual  prototype,  which  is 
hardware  independent,  or  technology  transparent.  The 
library  of  algorithms,  models  and  workshops  is  made 
available  not  only  for  initial  development,  but  also  for 
upgrades,  thus  providing  a  further  ‘hedge’  against 
subsequent  obsolescence  effects. 

The  use  of  commercial  database  tools  and  information 
exchange  service  to  mitigate  obsolescence  was 
promoted  by  ‘i2’,  who  now  own  TacTech  (paper  31). 
The  tool  provides  a  notification  process,  replacement 
options  and  component  usage  assessment  for  single  or 
multiple  projects.  The  availability  libraries  are  updated 
daily  and  form  the  backbone  of  this  information 
system,  which  is  primarily  an  aid  to  legacy  system 
obsolescence  management,  and  is  used  as  an 
obsolescence  notification  service  by  many  Defence 
equipment  suppliers  in  NATO  countries. 

A  beneficial  approach  to  using  COTS  software  and 
simulation  tools  in  Defence  Systems  was  presented  by 
Virtual  Prototypes  Inc.,  in  the  form  of  their  Enterprise 
Software  Framework,  (paper  11)  VPI  claim  that  their 
software  will  mitigate  obsolescence  effects  through 
reduction  in  technical  and  schedule  risk  by  machine 
generation  of  code  and  re-use  of  knowledge  and 
information. 

The  need  for  different  strategies  to  be  applied  to 
different  product  types;  i.e.  existing  ‘legacy’  products 
and  new  development  products,  was  recognised  in  the 
next  presentation  (paper  12).  Legacy  products  are,  by 
and  large,  dealt  with  by  a  passive  strategy,  corrective 
action  being  applied  on  a  reactive  basis.  New 
programmes,  however,  take  proactive  obsolescence 
management  as  a  key  design  requirement.  Advanced 
design  criteria  and  the  use  of  open  architecture 
concepts  with  COTS  device  families  is  the  basis  of  this 
new  approach.  Hardware  and  software  functional 
standardisation  is  driven  deeply  into  the  open 
architecture  design;  modularity  at  sub-module  level 
increases  hardware  robustness.  Selection  of  COTS 
devices  is  a  defined  process  with  key  components 
selected  to  have  a  good  commercial  availability  in 
‘Industrial  Quality  Level’,  have  multiple  suppliers  and 
be  compatible  with  the  most  popular  backplane  buses 
and  standard  interfaces.  The  open  system  architecture 
is  modular  and  scalable,  and  arranged  in  layers  with 
clearly  identified  logical  and  physical  interfaces,  and 
with  global  and  local  bus  networks  selected  for 
longevity  as  well  as  performance.  System  design  has 
recognised  that  software  package  development  and 
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certification  significantly  outstrips  the  equivalent 
hardware  process  in  most  cases,  and  used  standard 
COTS  OFP  software  factories  and  COTS  operating 
systems  to  minimise  the  impact  of  software 
obsolescence.  The  building  blocks  of  this  proactive 
approach  are:  the  open  architecture  and  modular 
design,  which  permit  changes  and  updates  with  a 
reasonable  level  of  risk  and  cost;  a  product 
configuration,  which  is  maintained  for  a  specific  period 
by  last  time  buys  per  batch  and  minor  changes;  and 
finally,  by  a  planned  periodic  product  enhancement 
permitting  obsolescence  removal  activities  with 
relevant  design  enhancements. 

Paper  32,  which  followed,  was  a  somewhat  esoteric 
treatise  on  methods  for  making  classified  documents 
more  secure  from  copying  using  a  variety  of 
techniques.  The  paper  was  a  late  addition  provided  by 
the  Hungarian  hosts,  and  was  relevant  to  this  section  in 
that  it  involved  software  tools  &  techniques,  although 
it  did  not  directly  reference  obsolescence. 

The  final  paper  (paper  14)  in  the  session  reviewed  the 
tools  and  methods  employed  by  Thomson  CSF  Group 
to  combat  obsolescence.  These  tools  operate  on  four 
levels  that  equate  to  a  flexible  response  strategy, 
tailored  to  project  and  customer  needs.  Customers  in 
different  markets  react  differently  to  the  problems  of 
obsolescence,  but  it  is  ultimately  the  equipment 
manufacturer  who  must  resolve  the  problem,  and  thus 
must  equip  themselves  with  the  means  to  do  so.  To 
ensure  consistency  of  approach  across  a  disparate 
group,  TCSF  set  up  a  common  obsolescence  control 
system,  with  common  tools  and  methods,  which  are 
applied  at  the  appropriate  stage  of  an  equipment’s  life 
cycle  and  level  of  maturity.  The  tool-set  encompasses 
reactive  and  proactive  elements,  including  an 
obsolescence  warning  system,  an  end  of  life  predictor 
tool,  a  knowledge-based  technology  evolution 
predictor  tool,  parts  list  analysis  and  review  processes, 
and  all  overseen  by  an  obsolescence  task  team  whose 
role  is  to  help  business  units  formulate  solutions. 
Since  ‘upstream’  obsolescence  risk  mitigation  is  rooted 
in  technical  choices,  TCSF  has  evolved  an  incremental 
design  procedure,  which  allows  for  technology 
refresh/insertion  throughout  the  product  lifecycle. 
Overall,  this  approach  is  exemplary  and  must  be 
commended.  That  such  a  complex  organisation  has  so 
clearly  identified  the  issues  of  obsolescence 
management  and  empowered  a  structure  to  deal  with  it 
so  comprehensively  reflect  well  on  their  management. 


Session  III  -  New  Design  Concepts  and 
Architectnres  to  Combat  Obsolescence. 

The  third  session  contained  eleven  papers,  in  which  the 
major  themes  examined  were  modular  and  open 
architectures,  associated  software  techniques,  and 
system  design  for  flexibility  and  obsolescence 
mitigation.  The  opening  two  papers  were  concerned 
with  aspects  of  the  Allied  Standardised  Avionics 


Architecture  Council  (ASAAC)  project,  whose  prime 
objective  is  to  define  a  flexible  avionics  architecture 
that  will  balance  affordability  constraints  with  combat 
capability  and  combat  availability.  Principally 
ASAAC  is  aimed  at  reducing  life  cycle  cost  and 
improving  operational  performance.  The  architecture 
described  in  paper  16  is  open,  the  logical  structure  is 
layered,  and  is  the  basis  for  integrated  modular 
avionics  populated  by  common  functional  modules, 
with  defined  physical  and  logical  interfaces. 

An  example  of  this  approach  was  given  in  paper  15, 
where  a  Mission  Management  System  (MMS)  is  being 
developed  using  the  ASAAC  structures.  This  MMS 
makes  extensive  use  of  COTS  hardware  and  software 
technology,  has  functional  modularity  and  open 
architecture  for  technology  transparency. 

An  alternative  solution  presented  in  paper  17,  is  that  of 
system  on  chip.  These  devices  contain  CPU  cores  and 
DSP  functions,  with  defined  standard  interfaces.  The 
design  flow  is  based  on  that  outlined  by  the 
COCISPER  consortium  in  paper  8  above.  The  device 
is  created  as  a  virtual  component  defined  in  VHDL, 
and  as  such  is  technology  transparent;  and  the  use  of 
virtual  prototyping  speeds  development  and  upgrades, 
thus  reducing  life  cycle  costs. 

Paper  18,  described  the  development  of  an  open 
computer  system  for  military  avionics,  using  COTS 
computer  components.  This  universal  aircraft 
computer  (UAC)  is  constructed  from  well-established 
commercially  available  hardware  and  software  and  has 
a  layered  open  architecture,  enabling  software  to  be 
ported  to  different  hardware  configurations  with 
minimum  effort. 

The  embodiment  of  COTS  components  and  modules  in 
a  modem  avionics  architecture  was  described  in  the 
next  presentation  (paper  19).  In  upgrading  the  avionics 
suite,  extensive  use  was  made  of  COTS  general 
aviation  equipment  and  COTS  Processors  and 
Displays.  The  result  is  a  state  of  the  art  system,  which 
is  cost  effective  with  reduced  development  risk  and 
improved  supportability. 

The  next  paper  (paper  20)  described  the  use  of  a 
distributed  architecture  as  the  basis  for  a  computing 
system  that  is  fault  tolerant,  uses  COTS  systems  and 
re-uses  obsolete  CPUs. 

Strategies  developed  by  EADS  for  dealing  with 
obsolescence  were  outlined  in  paper  21.  They 
recognize  that  80%  of  overall  product  costs  are 
committed  in  the  first  20%  of  the  development  cycle, 
therefore  the  problem  of  DMS  needs  to  be  addressed  at 
the  earliest  stage  -  when  the  architecture  is  being 
defined.  A  modular  hardware  approach,  using 
functional  building  blocks,  together  with  a  layered 
software  model  reminiscent  of  the  ASAAC  approach, 
and  standard  interfaces,  produces  a  flexible  design  that 
can  accommodate  frequent  updates.  Additionally,  they 
are  investigating  the  creation  of  a  moderate  thermal 
and  mechanical  environment  to  accommodate  the 
increasing  use  of  commercial  components. 
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That  we  should  take  an  holistic  view  of  obsolescence 
was  argued  by  the  next  speaker  (paper  22).  Electronic 
component  unavailability  is  just  a  ‘special  case’  of  the 
general  form  of  obsolescence  that  arises  when  a  system 
no  longer  provides  and  adequate  solution  to  a  user’s 
problem.  Obsolescence  Management  needs  to  plan  for 
continuous  change.  A  system  engineering  approach  is  a 
structured  way  of  taking  the  holistic  view,  and 
obsolescence  is  now  a  key  element  in  the  system 
engineering  methodology. 

The  ever-increasing  cost  of  software  obsolescence  and 
techniques  for  reducing  it  were  illustrated  with 
reference  to  the  development  of  a  demonstrator  Radar 
Data  Processor  (paper  23).  The  key  elements  in  this 
process  were  the  creation  of  integrated  Systems  and 
Software  teams;  the  use  of  state  of  the  art  software 
tools;  and  the  implementation  of  the  Rapid  Object- 
oriented  Process  for  Embedded  Systems  (ROPES) 
methodology.  Mitigation  of  obsolescence  comes  from 
the  ability  to  re-use  sub-systems. 

Paper  24  continued  the  theme  of  using  software 
flexibility  to  insulate  hardware  from  the  ravages  of 
obsolescence.  The  example  given  was  a  software  radio 
for  multi-band,  multi-mode  and  multi-role  operation. 
Again  the  utilisation  of  a  modular  architecture,  and  a 
sharp  division  between  hardware  and  software,  permits 
low  risk  module  replacement  to  overcome 
obsolescence  impacts. 

The  final  paper  in  this  session  (paper  25)  considered 
test  equipment,  which  is  often  the  last  equipment  to  be 
considered,  but  can  suffer  obsolescence  effects  as 
readily  as  the  front  line  product.  Test  system 
architectures  must  achieve  long  term  maintainability, 
whilst  being  regularly  updated  to  keep  abreast  of  the 
equipment  under  test.  EADS  adopted  a  ‘philosophy  of 
standardised  units’  and  defined  the  test  set  critical 
interfaces,  allowing  them  to  develop  a  modular  system 
that  can  evolve  through  hardware  and  software  module 
replacement.  The  system  makes  maximum  use  of 
COTS  equipment,  software  and  protocols. 


Session  IV  -  Strategies  and  Initiatives  for  Lifecycle 
Management. 

The  five  papers  in  this  session  examined  the  use  of 
COTS  and  COTS-based  systems  from  a  life  cycle 
management  perspective.  The  first  paper  (paper  26) 
very  coherently  summarised  the  management 
challenges  thrown  down  by  COTS-based  IT  systems  in 
Defence  acquisition. 

Whilst  COTS  offer  the  promise  of  being  ‘faster,  better, 
cheaper’,  they  also  come  with  more  rapid 
obsolescence,  lack  of  control,  lack  of  underlying 
design  detail,  out  of  step  with  military  requirements 
etc.,  and  management  cognition  of  these  difficulties  is 
essential.  COTS-based  systems  are  inherently 
complex  and  require  adequate  resource  to  be  applied 
throughout  the  life  cycle,  since  a  COTS-based  system 
is  effectively  in  a  state  of  continuous  design 


improvement.  This  means  that  the  total  lifetime  costs 
of  such  a  system  is  impossible  to  accurately  predict  at 
this  time,  and  this  conflicts  with  current  Defence 
acquisition  strategies.  The  complexity,  and  potential 
variety,  of  COTS-based  systems  demands  a  paradigm 
shift  in  the  management  approach  of  all  stakeholders, 
from  suppliers  to  end-  users. 

The  theme  of  the  management  challenge  of  COTS  was 
continued  in  the  second  paper  (paper  27)  of  the 
session.  Recognition  that  COTS  means  constant 
change,  must  lead  to  planning  for  change  and  for 
operating  with  multiple  configurations  and  open 
systems.  Procurer  and  supplier  must  work  together  in 
a  win-win  stakeholder  relationship  to  ensure  cost- 
effective  and  timely  decision-making. 

The  paradigm  shift  needed  between  traditional  and 
COTS-based  acquisition  is  highlighted  in  the  third 
presentation  (paper  28),  which  uses  the  example  of 
Software  COTS  items.  Control  and  visibility  are  key 
issues,  which  become  problematical  with  COTS 
software,  and  its  open  commercial  nature  necessarily 
means  that  it  is  available  to  potential  enemies.  The  use 
of  open  source  software  such  as  Linux  Operating 
System  (OS)  offers  the  control  and  visibility  of 
bespoke  software,  without  the  cost,  and  promises  vital 
advantages  in  dealing  with  obsolescence  in  that 
appropriate  changes  can  be  made  to  the  OS  such  that 
the  application  suite  need  not  be  altered.  The 
flexibility  and  modularity  of  Linux  make  it  complex  to 
specify  for  procurement.  A  Linux  Centre  is  proposed 
to  act  as  a  focus  for  the  needs  of  the  Defence 
community  who  want  to  use  Linux,  whilst  maintaining 
links  to  the  global  Linux  community. 

The  penultimate  paper  (paper  29)  discussed  a  new 
approach  -  an  integrated  Reduced  Total  Cost  of 
Ownership,  which  sets  out  to  show  that  new 
technology  can  reduce  the  life  cycle  cost  of  an  aircraft 
by  over  40%,  despite  conservatism  in  the  cost 
estimating  community.  Extensive  use  of  Design  for 
Manufacture  and  Assembly  computer  aided 
engineering  and  re-engineering,  enabled  significant 
reductions  in  parts  count  and  assembly  cycle  times  to 
be  realised  and  improvements  in  reliability  and 
maintainability  achieved.  The  study  concluded  that  the 
integration  of  new  technology,  flexible  acquisition 
systems  and  advanced  processes  can  reduce  cost  of 
ownership  of  aerospace  systems. 

The  final  paper  (paper  30)  of  the  Symposium  very 
effectively  summed  up  the  current  reality  of 
obsolescence  management,  which  is  generally  reactive, 
and  that  individuals  solving  individual  problems  was 
wasteful  of  scarce  resources.  The  speaker  described  a 
National  Obsolescence  Centre,  which  would  address 
obsolescence  on  a  Global  basis.  The  Centre  would 
combine  the  resources  of  DERA  and  industry  and 
provide  a  single  focus  for  obsolescence  information 
and  an  affordable  obsolescence  management  service  to 
small  and  medium  sized  companies,  who  would 
otherwise  struggle  to  afford  effective  solutions  to  their 
obsolescence  problems.  It  could  also  act  as  a  focal 
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point  for  promotion  of  new  approaches  such  as  Physics 
of  Failure,  Health  Unit  Monitoring,  and 
maintenance/failure  free  operating  periods  as  part  of  a 
built  for  life  electronics  project.  The  combination  of 
maintenance  /failure  free  operating  periods  with  open 
systems  architectures  could  offer  a  low  cost  solution  to 
the  obsolescence  problem  as  well  as  providing  planned 
seamless  technology  upgrades  and  known  equipment 
reliability. 

Conclusions. 

The  Symposium  was  attended  by  128  individuals,  from 
21  countries,  and  the  overwhelming  view  expressed  by 
the  attendees  who  returned  questionnaires,  was  that  the 
event  had  been  very  good  to  excellent.  Most  people 
considered  that  it  had  been  very  worthwhile,  and  that 
the  theme  of  the  symposium  was  very  appealing  and 
topical.  The  papers  presented  were  judged,  in  the 
main,  to  have  met  the  objective  of  the  symposium  and 
were  of  a  satisfactory  level  and  mostly  relevant  to  the 
theme  of  the  conference.  There  was  a  similar  level  of 
satisfaction  expressed  with  regard  to  the  organisation 
of  the  speakers  and  their  use  of  visual  aids,  and  the 
time  allowed  for  their  presentations  and  for  discussion 
and  exchange  of  ideas. 

Two  papers,  paper  14  on  the  comprehensive  tools  and 
techniques  employed  by  Thomson-CSF  in  their  efforts 
to  combat  obsolescence  and  paper  26  on  management 
issues  involved  with  the  use  of  COTS  based  IT 
systems,  were  adjudged  the  most  interesting. 
However,  the  votes  were  very  widespread,  with  the 
papers  in  session  II  accruing  most  votes,  which  may  be 
a  reflection  of  the  composition  of  the  audience  which 
contained  a  high  proportion  of  Defence  Industry 
Contractors,  who  were  interested  in  the  practicalities  of 
obsolescence  management  today.  It  is  unfortunate  that 
there  were  so  few  attendees  from  the  Customer  and 
Procurement  communities,  since  the  lessons  learnt  and 
the  problems  still  encountered  would  have  been 
enlightening  for  those  who  effectively  set  the 
boundaries  within  which  the  majority  of  speakers  and 
attendees  must  function. 

In  general  the  organisation  of  the  Symposium,  the 
location  and  the  hospitality  of  the  Hungarian  hosts  was 
universally  approved.  One  minor  drawback  was  that 
the  translators,  who  were  excellent,  could  be  heard  a 
little  too  loudly  in  the  auditorium  due  to  a  lack  of 
adequate  sound  proofing  of  the  booths,  which  was 
distracting  to  those  at  the  rear  of  the  hall. 

The  major  technical  themes  dealt  with  in  the 
symposium  were: 

•  Obsolescence  management  of  current  or  legacy 
electronic  equipment  &  systems. 

•  Mitigation  of  the  effects  of  obsolescence  in  new 
designs. 


•  Discussion  of  the  pros  and  cons  of  using  COTS 
components  in  military  systems,  and  their  effect 
on  obsolescence  management. 

The  symposium  title  perhaps  implied  a  wider  debate 
than  that  which  it  exited,  as  many  presentations 
focused  on  the  problems  of  microcircuit  obsolescence 
in  electronic  equipment.  As  noted  earlier,  this  is 
understandable,  given  that  the  sharpest  pain  of 
obsolescence  is  currently  felt  by  equipment 
manufacturers  through  unavailability  of  advanced 
microcircuits.  The  problems  and  solutions 
encountered  in  this  area  should  be  regarded  as  a  special 
case  of  the  general  problem  of  obsolescence,  as 
pointed  out  in  paper  22,  and  they  have  ‘read  across’  to 
a  wider  spectrum  of  obsolescence  issues. 

The  keynote  speaker,  in  his  excellent  presentation, 
described  the  large  investment  made  by  the  DOD  to 
ensure  a  supply  of  microcircuits  for  their  legacy 
systems,  thus  effectively  warding  off  the  effects  of 
obsolescence  by  controlling  parts  supply.  Most 
Defence  contractors  rely  on  a  reactive  strategy  for  their 
legacy  systems,  e.g.  papers  12  &  14,  and  to  be 
effective  this  depends  upon  good  quality  obsolescence 
information,  which  can  be  supplied  internally  (paper 
14),  or  externally  by  a  commercial  venture  or 
government  sponsored  centre  (papers  31  &  30).  There 
is  no  one  solution  to  all  difficulties  resulting  from 
component  unavailability,  several  of  the  presentations 
made  this  clear.  Tailoring  of  the  obsolescence  solution 
to  the  customer  and  product  and  type  of  obsolescence 
is  required,  and  involvement  of  all  stakeholders  is  also 
necessary. 

Future  systems  demand  an  holistic,  systems 
engineering  approach,  to  the  threat  of  obsolescence. 
Unless  the  system  is,  from  the  outset  , designed  so  far 
as  is  possible  to  minimise  or  eliminate  obsolescence 
effects,  then  it  will  inevitably  succumb.  System 
designs  should  be  modular  in  both  hardware  and 
software,  and  should  employ  an  industry  standard  open 
system  architecture,  with  extensive  use  of  software 
tools  to  define  and  simulate  system  modules  thus 
making  the  system  design  technology  independent.  A 
number  of  papers  gave  examples  of  the  work  currently 
being  done  in  this  area,  papers  15,16,18  &21  all 
reference  the  AS  SAC  architecture  which  looks  very 
much  like  a  basis  for  future  products.  This  architecture 
has  a  ‘layered’  software  structure,  and  this  is  essential 
if  the  costs  of  software  upgrades,  initiated  by  hardware 
obsolescence,  are  not  to  spiral  out  of  control.  The 
whole  vexed  question  of  software  obsolescence  was  in 
general  presented  within  the  context  of  hardware 
initiated  changes.  Techniques  for  lessening 
obsolescence  effects  on  software  were  described  in 
paper  23,  and  such  techniques  will  be  crucially 
important  to  future  project  cost  containment.  In 
proportion  to  the  potential  costs,  insufficient  debate  on 
software  obsolescence  was  presented  at  this  event. 
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The  proactive  system  engineering  design  approach  is 
also  an  essential  part  of  the  use  of  COTS  components 
in  military  systems.  COTS  can  be  used  as  a  solution 
for  obsolescence,  but  only  short  term,  since  they  are 
subject  to  even  shorter  lifetimes  than  the  now 
vanishing  military  parts  as  outlined  in  paper  1.  COTS 
require  a  more  protected  environment  and  open 
architecture  modular  systems  with  planned  upgrades  to 
refresh  the  technology  and  insert  new  technology. 
Work  is  ongoing  to  improve  the  avionics  environment 
in  future  aircraft,  which  will  benefit  the  COTS  based 
equipment  (paper  5).  However,  management  issues 
regarding  the  use  of  COTS  and  COTS-based  systems 
need  a  rethink  of  the  procurement  process.  A 
paradigm  shift  is  required;  the  traditional  adversarial 
procurement  approach  is  too  inflexible  to  deal  with  the 
variety  and  complexity  of  COTS  equipment.  The 
partnership  approach  between  Government  and 
industry  should  be  promoted,  with  obsolescence 
identified  as  a  risk  to  be  jointly  managed.  The  issue  of 
support  of  fielded  COTS-based  equipment  raises  the 
question  of  the  level,  and  location,  of  repair,  and 
demands  smart  solutions. 

It  is  obvious,  from  the  presentations  and  attendees,  that 
the  effects  of  obsolescence  are  so  universal,  we  must 
work  collectively  to  establish  common  solutions,  rather 
than  devise  individual  solutions  to  common  problems. 
Working  through  organisations  such  as  the  National 
Obsolescence  Centre,  or  the  Component  Obsolescence 
Group  (COG)  in  the  UK,  DMEA  in  the  US,  and  so 
forth,  is  the  way  forward  for  the  many  small  to 
medium  sized  companies  in  the  Defence  business. 


Recommendations 

This  Symposium  was  timely,  as  the  unavailability  of 
state  of  the  art  military  parts  means  that  COTS  are 
virtually  ‘the  only  game  in  town’,  and  unless 
cognizance  is  taken  of  the  issues  associated  with  their 
use  in  military  systems  costs  will  spiral  beyond 
control.  Further,  as  the  cycle  of  change  for  hardware 
shortens,  the  costs  and  effort  associated  with  software 
upgrades  dominates  the  project.  Thirdly,  planned 
technology  insertion  strategies  will  incur  the  overhead 
of  re-qualification/re-certification,  and  area  not  much 
discussed  at  this  event. 

For  future  work,  I  would  recommend: 

•  A  Workshop  on  the  management  issues  associated 
with  the  procurement  and  use  of  COTS 
components  and  COTS-based  systems,  and 
targeted  at  the  customer  and  procurement 
communities.  This  should  include  consideration 
of  the  effects  of  widespread  use  of  COTS  on  the 
Logistic  Support  community. 

•  A  Workshop  or  Symposium  on  Software 
Obsolescence. 

•  A  Workshop  dealing  with  the  problems  of  re- 
qualification/re-certification  of  military  equipment 
which  is  subject  to  planned  technology  insertions. 

•  A  workshop  addressing  cost  forecasting  for 
COTS-based  systems. 


Overall,  the  author  feels  that  the  Symposium  satisfied 
its  objectives,  and  provided  a  beneficial  exchange  of 
ideas  and  information. 


■ 
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United  States  Department  of  Defense  Initiatives  for  the 
Management  and  Mitigation  of  Microelectronics  Obsolescence 

Mr.  Ted  Glum,  Director 

US  Defense  Microelectronics  Activity,  DUSD  (L&MR)/DMEA 
2434  54*^  Street,  McClellan  AFB 
CA  95652,  United  States 

The  United  States  Department  of  Defense  (US  DoD)  and  its  aiiies  increasing  reiy  on  “smart”  weapon 
systems  to  provide  both  a  strategic  and  tacticai  edge  on  the  battiefieid.  The  components  that  make 
these  systems  smart  are  the  compiex  microeiectronics  devices  that  form  the  core  of  their  functionai 
capabiiity.  However,  this  same  semiconductor  technoiogy  upon  which  we  reiy  turns  over  every  18 
months  or  iess  and  is  normaiiy  supported  for  no  more  than  six  to  seven  years.  Yet  the  US  DoD  and 
its  aiiies  keep  their  weapon  systems  in  operation  for  ever-increasing  periods  of  time,  and  often 
requiring  the  avaiiabiiity  of  “unique”  microeiectronics  devices  for  20  or  more  years.  Therefore,  the 
probiem  facing  the  DoD  and  its  aiiies  is  not  the  abiiity  to  acquire  advanced  technoiogy  during  weapon 
system  deveiopment,  but  rather  the  inabiiity  to  acquire  this  technoiogy  during  the  out-years  in  order  to 
keep  hi-tech  weapon  systems  supported.  This  emphasizes  the  need  for  the  deveiopment  of 
management  techniques  and  soiution  based  strategies  to  handie  the  probiem  of  microeiectronics 
obsoiescence. 

Commerciai  Use  Of  Technoiogy  Drives  the  Market 

In  today’s  global  economy,  the  US  DoD  represents  less  than  3%  of  the  world  semiconductor  market. 

In  this  environment,  a  Defense  customer,  supporting  a  fielded  weapon  system,  usually  has  a 
requirement  for  several  hundred  or  perhaps  several  thousand  of  a  particular  microelectronic  device. 
However,  these  customers  must  compete  against  large  high-volume  commercial  interests  (i.e., 
cellular  telephones,  personal  computers,  network  switching  systems,  etc.).  These  commercial 
requirements  demand  access  to  the  newest  technologies,  with  parts  orders  in  the  millions  of  devices. 
Semiconductor  manufacturers,  who  make  decisions  based  upon  profitability,  tend  to  move  with  the 
market  place.  In  the  case  of  military  versus  commercial  applications,  the  trend  shows  manufacturers 
closing  their  low  volume,  less  profitable  military  product  lines  and  concentrating  on  their  highly 
profitable,  high  volume  commercial  product  lines.  The  problem  only  worsens  as  we  look  at  the  big 
picture. 

The  Problem  is  Compounded 

It  is  a  fact  that  Microelectronics  obsolescence  is  a  horizontal,  technology-based  issue  rather  than  a 
vertical  one,  since  systems  throughout  the  entire  US  DoD  use  the  same  or  similar  microelectronics 
devices.  Simply  put,  when  a  device  becomes  obsolete,  every  weapon  system  using  that  device  has  a 
problem.  With  reduced  Operations  and  Support  funds  available,  wholesale  replacement  of  fielded 
systems  is  increasingly  unaffordable.  Complicating  the  picture  even  further  is  the  need  of  the  US  DoD 
and  its  allies  for  5  Volt  logic  device  technologies,  which  have  been  designed  into  our  weapon  systems 
over  many  years.  But  at  the  same  time,  industry  is  rapidly  abandoning  5  Volt  logic  in  favor  of  3.3  Volt 
and  lower  voltage  circuits. 

As  it  is  true  of  the  problem,  the  solution  must  have  the  ability  to  cut  across  the  many  weapon  systems 
throughout  the  entire  DoD.  Therefore,  the  DoD  established  an  organization  to  combat  this  area  of 
critical  concern. 

The  US  Defense  Microelectronics  Activity  -  The  Key  to  US  DoD  Initiatives 
On  23  July  1996,  the  Deputy  Secretary  of  Defense,  The  Honorable  Mr.  John  White,  issued  a 
memorandum  establishing  the  Defense  Microelectronics  Activity  (DMEA).  The  DMEA  was 
established  by  the  Department  of  Defense  to  provide  a  broad  spectrum  of  microelectronics  services  to 
US  DoD.  The  DMEA,  located  in  Sacramento  California  -  close  to  Silicon  Valley,  is  under  the  authority, 
direction  and  control  of  the  Deputy  Under  Secretary  of  Defense  for  Logistics,  Readiness  &  Material 
Management. 

Its  primary  mission  is  to  leverage  the  capabilities  and  payoffs  of  advanced  microelectronics 
technology  to  solve  US  DoD  operational  problems  in  existing  weapon  systems,  increase  operational 
capabilities,  reduce  operation  and  support  costs,  and  reduce  the  effects  of  Diminishing  Manufacturing 
Sources  (DMS)/obsolescence  for  microelectronics  components.  In  this  capacity,  the  DMEA  assists 
weapon  systems  managers,  and  managers  of  other  operational  or  developmental  systems,  in 
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inserting  advanced  microeiectronics  technoiogies,  ensuring  lifetime  sustainment  of  these  systems 
which  are  dependent  on  microelectronics,  and  provide  studies  and  analysis  relative  to  existing  or 
future  obsolescence  problems.  It  addition  to  supporting  US  Defense  organizations,  the  DMEA  acts  as 
a  resource  to  other  federal  agencies,  state  governments,  U.S.  industry  and  foreign  entities. 

Another  established  role  is  as  the  US  DoD’s  Executive  Agent  for  Integrated  Circuit  (1C) 
Microelectronics  DMSMS.  As  such,  DMEA  is  a  key  player  in  the  development  and  coordination  of 
solutions  to  US  DoD’s  obsolescence  problems  and  is  responsible  for  issues  relating  to  1C 
microelectronics  obsolescence.  In  this  role,  DMEA  has  developed  several  key  initiatives  for  the  US 
DoD  to  curb  the  effects  of  microelectronics  obsolescence. 

DoD-DMEA  Initiatives 

Acquisition  Guideiines-  A  comprehensive  guidebook  developed  to  provide  the  tools  and  techniques 
necessary  to  assist  government  decision  makers,  weapon  system  program  managers,  integrated 
product  teams,  and  support  personnel  during  all  phases  of  the  weapon  system  acquisition  process. 
The  goal  is  to  reduce  the  costs  associated  with  microelectronics  obsolescence  by  using  “smart 
procurement”  strategies. 

Advanced  Technoiogy  Support  Program  -  Provides  rapid  access  to  in-house  DMEA  engineering 
capability,  including  its  microelectronics  engineers  and  “world  class”  laboratory  facilities  containing 
$200M  USD  of  engineering  analysis,  design,  test  and  limited  production  equipment.  This  unique 
enterprise  also  provides  access  to  the  United  State’s  top  defense  contractors  through  the  program’s 
$875M  USD  in  contracts.  This  strategy  offers  defense  agencies  a  comprehensive  mix  of  solutions 
through  a  unique  and  synergistic  combination  of  government  and  industry  expertise.  Program 
activities  range  in  complexity  from  discrete  electronics  through  integrated  circuits,  circuit  boards, 
modules,  assemblies,  subsystems,  and  systems.  Typical  solutions  include  developing  form,  fit  and/or 
function  (FEE)  replacements  and  advanced  technology  insertions  and  applications. 

Best  Management  Practices  -  DMEA  developed  in  cooperation  with  US  Military  services  and  Industry 
Groups  a  step-by-step  strategy  document  for  managing  microelectronics  obsolescence.  It  provides 
practical  techniques  and  approaches  to  aide  weapon  system  support  personnel  in  establishing  a 
multi-level  -  comprehensive  microelectronics  obsolescence  management  program.  It  is  applicable  for 
use  at  all  stages  of  the  weapon  system  life  cycle. 

DMEA  Flexible  Foundry -“The  Ultimate  Insurance  Policy” 

The  DMEA  Flexible  Foundry  was  established  to  solve  the  problem  of  long-term  microelectronics 
availability  for  military  weapon  systems.  This  unique  capability  provides  the  means  to  fabricate  a  vast 
array  of  obsolete  microelectronic  devices  as  well  as  cutting  edge  technologies.  This  one-of-a-kind 
facility  is  located  at  DMEA  in  Sacramento,  California  -  USA. 

Through  the  flexible  foundry,  DMEA  has  solved  the  problem  of  microelectronics  availability  from  now 
closed  or  discontinued  process  lines.  This  is  accomplished  through  successful  partnerships  with  the 
semiconductor  industry  by  licensing  and  fabricating  proven  industry  microelectronics  processes. 

These  processes  run  simultaneously  or  in  tandem  in  the  DMEA  foundry — thus,  it  is  a  Flexible 
Foundry. 

This  technical  and  business  model  assures  a  continued  US  DoD  supply  of  microcircuits  as  industry 
flexes  with  the  market — low  volume,  on-demand  requirements  can  be  met.  Logic  circuits,  amplifiers, 
regulators,  mixed  signal  ASICs,  gate  arrays  and  radiation-hardened  devices  are  but  a  few  of  the  types 
of  microcircuits  supported  by  the  Flexible  Foundry. 

Conclusion 

The  US  DoD  and  its  allies  face  the  daunting  challenge  of  managing  and  solving  the  problems  caused 
by  microelectronics  obsolescence.  World  economic  market  forces  are  quickly  eroding  the  clout  of  the 
once  powerful  military  industrial  complex,  as  once  steady  supplies  of  military  product  lines  are  pushed 
aside  for  more  profitable-high  volume  commercial  product  oriented  microelectronic  devices.  To  rise  to 
this  challenge,  the  US  Department  of  Defense  established  the  Defense  Microelectronics  Activity,  an 
organization  with  the  mission  to  address  the  full  spectrum  of  microelectronics  issues.  Through 
innovative  strategies,  the  DMEA  has  developed  a  series  of  initiatives  to  help  the  US  DoD  and  its  allies 
manage  and  solve  their  problems  of  microelectronics  obsolescence.  DMEA’s  “Flexible  Foundry”, 
meets  long-term  defense  requirements  by  providing  a  future  source  for  critical  microelectronics 
technologies  for  our  “smart”  weapon  systems. 


1-1 


The  Use  of  Commercial  Components  in  Defense  Equipment 

to  Mitigate  Obsolescence. 

A  Contradiction  in  Itself  ? 


by 

Lutz  Petersen,  Dipl.  Ing. 

Head  of  Program  Management 
TELDIX  GmbH 
PO-Box  105608 
D-69046  Heidelberg 
Germany 


(October  2000) 


Abstract: 

The  paper  identifies  and  discusses  the  presently 
unresolved  contradictions  between  the  requirements 
of  the  national  customers  (MODs  or  Purchasing 
Agencies)  and  the  viable  options  the  industry  can 
offer  to  mitigate  the  adverse  effects  of  obsolescence 
for  defense  material  with  emphasis  on  the  extended 
use  of  COTS. 


Twenty  years  ago  the  main 
technical  discussion  topic 
within  the  defense  industry 
was  technological  progress 
and  achievements.  Today 
we  have  become  prisoners 
of  this  progress  and  are 
increasingly  unable  to 
keep  pace  with  the 
technology.  Instead  we 
have  to  deal  with  the 
antithesis  of  progress  - 
outdated  or  obsolete 
components.  Obsolescence 
concerns  suppliers  and 
customers  in  different 
ways  but  in  any  case  the 
result  is  painful  since 
obsolescence  has  adverse 
effects  on  our  business.  There  is  no  way  to  defeat 
obsolescence,  it  has  properties  like  gravity,  it  lurks 
everywhere  in  our  electronics  world  and  it  will  stay.  We 
have  to  accept  it  like  a  law  of  physics  and  as  a  fact  of  our 
professional  -  and  our  private  -  life.  When  1  studied 
electronics  engineering  in  the  sixties,  1  used  to  make 
some  money  by  repairing  TV  sets.  My  stock  of  spares  to 
repair  a  hundred  or  even  more  different  sets  easily  fitted 
into  a  briefcase  and  consisted  of  some  20  electron  tubes 
and  a  handful  of  resistors  and  capacitors.  Have  you  ever 
tried  to  get  your  5  year  old  Korean  Video  Cassette 
Recorder  repaired?  -  an  ambitious  task  which  will 
frustrate  you  quickly  and  will  probably  result  in  the 
acquisition  of  a  new  one  for  200  bucks  or  even  less.  In 


all  probability  you  would  not  even  have  tried  since  you 
wanted  a  new  one  anyway. 

Let  me  get  this  straight  from  the  very  beginning. 
Obsolescence  is  a  very  big  problem  for  the  supplier 
industry.  It  has  not  been  created  by  the  industry  -  as 
some  may  see  it  -  as  a  welcomed  source  for  additional 
revenue. 


Figure  1  -  Typical  Aircraft  Program  and 
Semiconductor  Life  Cycles 

To  analyze  the  task  at  hand  we  have  to  have  a  look  at 
the  life  cycles  of  both,  our  advanced  weapon  systems 
and  the  microelectronics  driving  it.  Figure  1'  clearly 
illustrates  the  conflict  we  are  in. 

Whereas  the  life  cycles  of  our  weapon  systems  have 
become  increasingly  longer  and  exceed  in  many  cases 
50  years,  the  introduction  cycles  of  new  commercial 
microelectronics  families  average  approximately  2  to  4 
years,  for  memory  devices  they  are  as  short  as  9 
months.  And  the  trend  is  continuing. 


Aircraft  Program  Cornerstones 


Average  Introduction  Rate  For 
New  Generations  of  Commercial 
integrated  Circuits 


□  start  of  Development  -1990 

□  Production  Investment  1998 
a  First  Production  Aircraft  2001 

□  Last  Production  A/C  2015  ? 

□  End  of  useful  life  2050  ?? 


LOGIC  FAMILIES . 6  YRS 

MEMORY  FAMILIES  .  .  .  .  9  MOS 


MICROPROCESSORS  .  .  .  2 YRS 


.3  YRS 


LL'JEAn  IfJ  rERFACES  .  .  .  U  i 
GATS  ArlrlAVS . 2  YrlS 


New  Technology 
Generation 
every  3  and  a 
half  years  for  an 
average  digital 
design 


^ow  Voltage  Digital  Technologies  Are  Projected  To  Last 
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System  Life  Cycle  is  50  years  (or  more) 
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Figure  2  -  Weapon  System  Life  Cycles 

Figure  2  shows  the  expected  life  cycles  for  selected 
weapon  systems  If  we  look  at  these  figures  and  on  the 
other  hand  at  the  life  cycles  of  the  semiconductor 
devices  driving  our  equipment,  it  becomes  apparent,  that 
we  have  to  deal  with  a  very  complicated  situation. 

Leaving  the  technical  aspect  aside  for  a  moment,  what 
does  this  mean  to  our  business?  It  clearly  shows,  that  our 
nice  and  shiny  high  tech  equipment  developed  today, 
introduced  into  service  in  3  to  4  years  time  or  even  later 
depending  on  the  weapon  system,  will  become 
unsupportable  in  2010  or  even  earlier.  We  will  simply 
not  be  able  to  procure  the  necessary  parts  for  production 
and  more  important  for  product  support  regardless 
whether  we  rely  on  commercial  or  military  components. 
The  only  difference  will  be,  that  with  the  use  of 
commercial  components,  our  problems  will  materialize 
earlier  because  of  the  shorter  life  cycles.  We  all  know 
the  sarcastic  definition  of  obsolescence  with  respect  to 
military  equipment: 

If  it’s  in  production,  it’s  obsolete, 
or  even  worse: 

Once  it’s  in  production,  it’s  obsolete 

Yes  of  course,  the  industry  has  developed  crutches  to 
survive  in  this  unpleasant  environment,  namely 


•  To  make  last  time,  life  time  or  bridge  buys  to 
protect  production  programs  and  to  support 
products  through  the  later  part  of  their  life  cycle. 
All  three  prone  to  error  and  are  the  antithesis  to 
modern  business  strategies.  They  create  inventory 
which  may  never  be  used  and  may  finally  have  to 
be  scrapped. 

•  To  purchase  parts  from  aftermarket  suppliers  -  at  a 
cost 

•  To  search  for  surplus  inventory  using  professional 
services  such  as  partsbase.com,  GSX,  LoKtor  or 
others  for  product  support 

But  whatever  we  do,  there  is  no  basic  difference  in  the 
employed  processes,  commercial  part  or  military,  the 
effort  and  the  results  are  in  general  the  same  and  the 
described  options  are  really  only  crutches. 

Let  me  tell  you  about  the  cruelties  of  the  obsolescence 
world.  A  few  years  ago,  we  were  notified  by  an  ASIC 
manufacturer,  that  the  production  process  of  one  of  our 
ASICs  was  going  to  be  obsoleted  shortly  and  that  we 
could  place  a  last  time  buy  order,  which  was  what  we 
did.  Since  we  were  not  in  urgent  need  for  the  parts,  we 
asked  the  supplier  to  store  the  dies  for  us.  When  we 
finally  retrieved  the  dies  from  the  nitrogen  and  wanted 
them  packaged,  we  discovered  ,  that  in  the  meantime 
the  package  had  become  obsolete  as  well,  making  a 
complete  re-layout  of  the  respective  CCA  necessary. 
Now  you  may  say,  that  a  top  notch  ASIC  supplier 
would  take  care  of  that.  Yes,  you  are  right,  but  we 
learned  the  hard  way  that  you  cannot  buy  insurance. 
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In  another  case,  we  were  notified  by  a  distributor,  that  a 
critical  part  had  become  obsolescent,  and  that  we  had 
exactly  6  working  days  to  place  our  last  time  buy  order. 
To  make  it  worse,  the  notification  arrived  on  Dec.  15* 
with  many  people  already  gone  for  season  vacation.  We 
should  also  bear  in  mind,  that  decisions  on  last  time  buys 
and  bridge  buys  need  some  careful  considerations  with 
respect  to  product  support  and  it  is  usual  practice  to 
agree  such  buys  with  the  customer,  unless  we  are 
prepared  to  accept  the  full  commercial  risk.  It  also 
clearly  illustrates,  that  the  issue  of  last  time  buy 
notifications  is  a  process,  which  is  not  very  disciplined, 
and  it  is  to  be  expected,  that  it  is  even  less  disciplined 
with  commercial  components  (figure  3  '“). 


Obsolescence  Notification 

□  Military  Components: 

^  Registered  letter  to  direct  customers  buying  within  5  years 
^  6  months  order  entry 
^  GIDEP 
^  WEB 

□  Commercial  Components: 

^  Letter  to  direct  customers  buying  within  2  years 
^  3  months  order  entry 

□  No  notification  to  distribution  customers  ! 

Source:  Texas  Instruments  a.-.,. 


Figure  3  -  Obsolescence  Notification 

Since  then  we  have  improved  our  obsolescence 
management  considerably,  with  the  result,  that  we  have 
much  better  visibility  today.  Nevertheless,  the 
obsolescence  problems  still  have  to  be  resolved  one  way 
or  the  other.  We  do  have  better  diagnostic  tools  today, 
but  there  is  still  a  very  sick  patient  out  there  and  no 
adequate  therapy  for  a  final  cure. 

But  let  me  get  back  to  my  initial  thesis.  Is  the  attempt  to 
mitigate  obsolescence  by  the  use  of  commercial 
components  a  contradiction  in  itself? 

As  we  all  know,  the  use  of  commercial  components  in 
military  equipment  creates  its  own  set  of  problems  as 
outlined  in  figure  4. 


COTS  Problems 

□  Short  life  cycles 

□  No  disciplined  obsolescence  notification  process 

□  Environmental  Conditions 

o  Temperature  /  Altitude  /  Humidity 
^  Nuclear  hardening 
Vibration 
Shock 
o  EMC 

□  Shrinking  parameter  margins 

□  Shrinking  structure  width 

o  Electromigration 
o  Dielectric  breakdown 


Figure  4  -  COTS  Problems 

We  have  to  deal  with  extreme  environmental 
conditions  like  high  and  low  temperature,  gun  fire 
vibration,  shock  and  sometimes  nuclear  hardening  - 
just  to  mention  a  few.  In  some  cases  we  have  to  drive 
the  devices  outside  the  specified  performance  envelope 
with  the  risk  of  unexpected  and  unknown  side  effects. 

In  other  cases  the  performance  envelope  of  the 
component  may  not  even  be  specified,  for  example 
Nuclear  Hardness.  In  other  cases  again  we  may  decide 
to  up-rate  our  devices,  which  is  in  itself  a  highly 
disputed  practice.  The  up-raters  claim,  that  this  is  the 
only  way  to  happiness  whereas  the  semiconductor 
industry  strictly  opposes  this  practice  with  good 
reasoning. 

The  use  of  Commercial  Off  The  Shelf  items  or  COTS 
in  military  equipment  has  been  sparked  off  by  the 
PERRY  DIRECTIVE  in  1994.  Some  of  Dr.  Perry’s 
original  wording  is  given  figure  5. 

After  careful  analysis  of  the  text  we  can  extract  4  major 
objectives,  which  are; 

1.  Quote  ...  that  we’re  going  to  rely  on  performance 
standards  instead  of  relying  on  mil  specs  to  tell 
our  contractors  how  to  build  something  ... 
unquote. 

2.  Each  system  is  to  use  the  lowest  grade  of 
component,  that  would  meet  the  environmental 
and  performance  requirement  of  the  system. 


Figure  5  -  Perry  Directive 


We  are  going  to  rely  on  performance  standards  ....  Instead  of  relying  on  mil  specs 
to  tell  our  contractors  how  to  build  something  ....  There  will  still,  of  course,  be 
situations  where  we  will  need  to  spell  out  how  we  want  things  to  be  built  in  detail.  In 
those  cases,  we  will  not  rely  on  mil  specs  but  rather  on  industrial  specifications...  In 
those  situations  where  there  are  no  acceptable  industrial  specifications,  or  for  some 
reason  they  are  not  effective,  then  the  use  of  mil  specs  will  be  authorized  as  a  last 
resort,  but  it  will  require  a  special  waiver.” 

Secretary  of  Defense  William  J. Perry,  press  conference  June  29,  1994 


1^ 


3.  Mil  specs  and  standards  should  only  be  used  as  a 
last  resort 

4.  Remove  requirements,  which  do  not  add  value. 

The  Perry  Directive  is  one  of  the  most  misunderstood 
and  misinterpreted  directives  in  our  business.  When  you 
read  it,  you  know  why,  since  there  is  a  lot  of  room  for 
misinterpretation.  It  does  not  say  we  must  use 
commercial  components  and  it  does  not  say,  that  all 
military  specification  are  void  either. 

In  the  wake  of  the  Perry  Directive  our  customers 
increasingly  insist  on  the  use  of  COTS  to  keep  up  with 
the  edge  of  technology  and  concurrently  reduce  cost.  At 
the  same  time  industry  is  faced  with  the  problem,  that 
despite  all  the  encouragement  to  make  extensive  use  of 
COTS  the  necessary  relaxation  of  the  associated 
implementation  requirements  in  our  specifications  -  how 
we  have  to  build  something  as  Dr.  Perry  has  put  it  - 
have  not  yet  come  along.  In  addition  we  still  have  to 
meet  the  tough  environmental  requirements  already 
mentioned  regardless  of  the  Perry  Directive.  As  a 
consequence  the  industry  ends  up  between  the  rock  and 
the  hard  place  and  has  to  accept  a  high  technical  and 
commercial  risk  when  acquiring  defense  contracts.  This 
situation  is  further  complicated  by  the  customer’s  - 
legitimate?  -  expectation,  that  due  to  the  use  of 
commercial  components,  the  equipment  acquisition  and 
support  cost  should  drop  significantly. 

All  this  is  happening  in  an  environment  of  steadily 
diminishing  supply  of  military  components,  and  rapid 
innovation  cycles  for  commercial  component  families, 
without  leaving  any  significant  purchasing  power  for  the 


equipment  supplier  industry  in  a  market,  which  is 
primarily  driven  by  telecommunication,  the  internet 
and  PC  industries  and  consumer  electronics.  Figure  6 
illustrates  the  semiconductor  market  as  of  1999 

In  a  press  release''  the  Semiconductor  Industry 
Association  announced  in  February  a  worldwide 
semiconductor  sales  figure  of  149  billion  US  dollars 
for  1999,  which  was  an  all  time  record.  In  the  same 
press  release  an  expected  growth  in  excess  of  20  %  for 
2000  and  2001  was  announced.  And  the  SIA  June 
figures'''  clearly  confirm  this  trend  with  an  actual 
growth  of  48.1  %  over  the  1999  figures  (figure  7). 

The  drivers  for  the  semiconductor  industry  are 
changing  rapidly  from  the  PC  industry  to  the  telecom 
and  internet  appliances. 


Commercial  vs.  Military  Semiconductor  Market 


□  Commercial  Market 

«  driven  by  Telecom,  Internet 
and  PC  Industries 
«  record  149  bn$  sales  In  1999 
(up  ia9%) 

«  20  %  growth  expected  In  2000 
and  2001  led  by  DSPs,  Flash 
MenxMy,  dedicated  telecom 
Circuits  and  Microprocessors 
=0  More  dedicated,  less  general 
purpose  microcircuits 


□  Military  Market 

=r>  no  drivers,  niche  market 
little  buying  power  despite 
volume  of  approx.  .6  to  1 
bn.$/yr. 

=r>  shrinking  vrstume 
=r>  diminishing  number  of 
suppliers 

=r>  diminishing  number  of 
components 


Figure  7  -  Commercial  and  Military  Semiconductor 
Market 


Figure  6  -  Semiconductor  Market 


Semiconductor  Market 
>=>  Military  Market  Share 


r=> 

1960 

>50% 

1976 

17% 

1986 

7.5% 

1996 

0.7% 

2000 

<0.4% 

>=>  Reduction  of  commercial 


interest  in  military  semiconductors  due  to 
■4>  Perry  Directive 
'=>  Deciining  miiitary  budgets 

'=>  Excessive  growth  of  commerciai  market  (teiecom,  internet,  PC) 
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While  in  1999  approximately  200  million  cell  phones 
were  sold,  the  SIA  is  expecting  a  market  volume  of  one 
billion  cell  phones  in  2003™  quintupling  the  market 
volume  in  four  years.  What  significance  has  the 
continuously  shrinking  military  semiconductor  market  of 
600  million  to  1  bn  US  $  /  yr.  in  this  context  despite  the 
volume  in  itself  being  impressive? 


equipment  in  question,  with  the  result  of  having 
different  build  standards  for  the  same  specification,  all 
of  which  will  satisfy  the  specification  in  all  aspects. 
Yes,  I  agree,  there  are  lots  of  arguments  not  to  do  this, 
such  as  qualification  and  re-qualification  problems, 
support,  configuration  issues,  customer  software  and 
other  problems  as  listed  in  figure  9. 


To  summarize  let’s  have  a  look  at  the  different  drivers 
for  obsolescence  and  the  use  of  COTS  on  the  other  side. 
It  appears,  that  both  issues  have  little  in  common,  except 
for  market  factors.  The  use  of  COTS  is  mainly 
commercially  driven,  whereas  obsolescence  is  basically 
technology  driven,  and  is  applicable  to  COTS  as  well, 
(figure  8) 


COTS  and  Obsolescence  Drivers 

□  COTS 

□  Obsolescence 

Perry  Directive 

=>  technical  progress 

=>  best  available  technology 

increasingly  shorter 

o  reduced  acquisition  cost 

innovation  cycles 

^  reduced  support  cost  ? 

=>  new  processes,  fab 

declining  military  budgets 

conversions,  larger 
wafer,  die  shrink 

=>  market  requirements 

=>  “Zero  Volt  Trend” 

o  market  requirements 

Is  the  market  the  only  common  denominator 

between  COTS  and  Obsolescence  ? 

Figure  8  -  COTS  and  Obsolescence  Drivers 
As  a  result  my  first  and  rather  trivial  theorem  is: 


Commercial  components  are  not  a  solution  to  the 
obsolescence  problem,  they  are  part  of  the  problem. 

But  still,  what  is  the  solution  to  our  Obsolescence 
problem? 


The  Black  Box  Approach 

□  Pros 

□  Cons 

=>  More  aligned  to 

New  way  of  thinking 

commercial  practices 

required 

=>  More  implementation 

Qualification 

freedom 

Software  portability 

=>  caters  for  technology 

=5  Only  Industry  Support 

insertion 

possible  ? 

o  caters  for  technology 

^  Configuration  Problems  ? 

transparency 

Changes  in  government 

=>  reduced  cost  of  ownership 

infrastructure  necessary  ? 

Figure  9  -  The  Black  Box  Approach 

This  does  not  mean,  it  cannot  be  done,  it  just  means 
that  we  have  to  be  more  creative  in  the  future  in 
dealing  with  these  issues.  This  will  require  close 
cooperation  of  all  involved  parties  from  government  to 
industry.  As  to  our  obsolescence  problem,  the  industry 
might  be  able  to  compensate  some  obsolescence  non 
recurring  cost  with  recurring  savings  which  may 
become  possible  by  value  engineering  and  the  use  of 
more  advanced  technology  throughout  the  life  cycle  of 
the  equipment.  Here  we  may  be  able  to  learn 
something  from  the  civil  aviation.  They  must  have  a 
very  similar  set  of  problems,  how  do  they  cope  with 
them? 

Dr.  Perry’s  second  objective  was: 

Each  system  is  to  use  the  lowest  grade  of  component, 
that  would  meet  the  environmental  and  performance 
requirement  of  the  system. 


Let’s  get  back  to  Dr.  Perry  for  a  while,  does  he  help  us 
with  our  problem?  What  do  the  four  objectives 
identified  earlier  really  mean  with  respect  to  our 
obsolescence  problem? 

As  we  remember.  Dr.  Perry’s  first  objective  was: 

Use  performance  based  specs. 

What  does  that  mean? 

A  first  step  on  our  way  to  deal  more  effectively  with 
obsolescence  may  be  the  adoption  of  a  black  box 
approach  for  our  equipment,  similar  to  the  practice  in  the 
civil  aviation  community.  That  means,  that  the  specifi¬ 
cation  defines  only  the  required  performance,  the 
environmental  conditions  and  the  interfaces,  but  no 
implementation  details.  What  is  inside  the  box  should 
be  left  to  the  supplier.  That  includes  bold  concepts  like 
technology  transparency  and  technology  insertion  for  the 


This  objective  amends  nicely  what  has  been  said  for 
objective  number  1.  It  will  remove  the  requirement  to 
use  the  highest  quality  grade  of  components,  freeing 
the  industry  to  select  the  quality  level  it  sees  fit  to 
fulfill  the  specification.  This  will  most  likely  have  a 
positive  impact  on  cost,  but  will  not  help  much  with 
our  obsolescence  problem. 

Dr.  Perry’s  third  objective  was: 

Mil  specs  and  standards  should  only  be  used  as  a  last 
resort. 

I  am  under  the  impression,  that  this  objective  has  gone 
totally  unnoticed  within  our  customer  community,  at 
least  in  Europe.  How  nice  would  it  be,  if  we  wouldn’t 
have  to  read  a  hundred  or  more  mil  specs  with  every 
RfQ. 
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Instead  I  find  more  and  more  mil  specs  in  the 
requirements  which  have  officially  been  cancelled 
already  or  which  are  totally  irrelevant,  nevertheless 
being  a  diligent  program  manager,  I  have  to  comply 
somehow  and  read  all  of  it. 

However,  the  objective  in  itself  is  a  good  one  and  we 
should  all  work  hard,  to  enlighten  our  customers,  that 
less  may  be  more. 

Now  some  may  say:  “What  do  I  care  about  the  Perry 
Directive,  I  am  here  in  Europe  and  have  nothing  to  do 
with  the  US  Government  Acquisition  practices”.  This 
may  be  true,  nevertheless  I  personally  think,  this  is  a 
rather  ridiculous  argument,  since  we  did  not  hesitate  at 
all  to  accept  the  excellent  system  of  mil  specs  and 
standards  during  the  cold  war.  Now,  as  the  US  DoD 
relies  more  and  more  on  COTS  and  has  started  to  send 
mil  specs  and  standards  into  retirement,  we  Europeans 
won’t  let  go. 

Dr.  Perry’s  fourth  objective  was.- 

to  remove  requirements,  which  do  not  add  value. 

In  my  humble  opinion  this  is  simply  common  sense, 
although  this  -  as  number  3  above  -  has  apparently  gone 
unnoticed  by  our  customers.  Everyone  in  the  industry 
familiar  with  government  acquisition  processes  must 
have  asked  himself  over  and  over  again:  “  why  the  hell 
do  they  want  this”.  In  many  cases  the  answer  is  simple: 
It  was  somewhere  in  the  model  text  the  author  has  used 
to  compile  the  specifications  or  the  request  for  quotation. 

Again,  the  removal  of  non  value  adding  requirements  is 
a  great  concept  and  would  alleviate  many  problems  in 
fielding  new  equipment,  it  may  also  help  to  reduce  cost 
and  time  to  market,  it  will,  however,  not  help  to  battle 
obsolescence. 

That  leaves  us  with  objective  number  one,  the  black  box 
approach  and  the  adoption  of  civil  procedures.  What 
other  options  do  we  have  to  alleviate  the  problem?  One 
way  that  has  been  generally  accepted  in  many  defense 
programs,  is  to  align  the  removal  of  obsolescence  with 
planned  weapon  system  upgrades.  In  order  to  enable  the 
industry  to  do  that,  a  much  better  visibility  as  to  the 
planned  upgrade  path  of  the  weapon  system  has  to  be 
provided.  This  again  requires  very  close  cooperation 
between  government.  Weapon  System  Contractor  and 
supplier  industry. 

I  have  to  admit,  this  might  only  be  a  first  small  step  and 
is  still  far  from  being  a  technical  solution.  And  we  need 
more  than  that.  We  have  to  have  both,  a  stable  and  sound 
technical  as  well  as  a  commercially  viable  business 
solution.  We  need,  however,  to  start  somewhere. 


In  my  effort  to  prepare  this  paper  I  searched  the 
internet  for  information  on  the  subject  and  to  my 
surprise  I  found  plenty  of  information  out  there. 
Actually  it  was  much  more  information  than  I  was  able 
to  digest  in  the  limited  period  of  time.  In  the  US  alone  I 
found  more  than  100  web  sites  and  34  different 
projects  dealing  with  the  obsolescence  problem,  most 
of  them  sponsored  by  the  DoD  or  the  services.  In 
addition  there  are  dedicated  DMSMS  program 
organizations  or  management  teams  in  place  to  deal 
with  obsolescence  for  a  specific  weapon  system  such 
as  for  the  B2  Bomber.  Much  work  has  been  done  in 
this  field  by  the  US  Air  Eorce  Materiel  Command,  the 
Defense  Logistic  Agency  (DLA),  the  Defense 
Microelectronics  Activity  (DMEA),  the  Government 
Industry  Data  Exchange  Program  (GIDEP),  the 
Generalized  Emulation  of  Microcircuits  activity 
(GEM)  but  also  by  private  enterprises  such  as  TacTech 
now  12  and  others.  None  of  these  activities  is  trying  to 
solve  the  obsolescence  problem  once  and  for  all  since 
there  is  no  such  solution.  All  activities  are  geared  to 
defining  and  providing  tool  sets  to  handle  obsolescence 
problems  as  they  occur. 

What  can  be  learned  from  these  activities,  which  again 
are  all  located  in  the  US,  is,  that  we  need  to  approach 
the  problem  on  a  much  higher  level,  with  all  entities 
involved,  be  it  industry  or  government,  working  much 
more  closely  together  to  keep  the  problem  under 
control.  The  progress  made  in  the  US  is  in  my  opinion 
mostly  to  be  attributed  to  the  fact,  that  the  Department 
of  Defense  and  the  services  with  their  organizations 
have  recognized  very  early  the  grim  facts  of 
obsolescence  and  have  proactively  promoted  a  variety 
of  activities  to  jointly  overcome  the  problem,  instead  of 
making  obsolescence  simply  a  problem  or  even  a 
liability  of  the  equipment  supplier  industry.  When  we 
review  what  has  been  achieved  in  the  US  already,  I 
feel,  there  is  a  lot  of  work  -  and  education  -  to  be  done 
in  Europe  to  catch  up.  And  in  doing  so,  we  should 
accept  the  experience  of  others  instead  of  re-inventing 
the  wheel.  Are  there  already  answers  available,  which 
we  do  not  use,  simply  because  we  do  not  know  about 
them? 

The  way  we  are  presently  trying  to  manage 
obsolescence  is  bottom  up,  everyone  solves  his  little 
problem  in  his  little  box  which  means  the  same 
problem  is  being  solved  over  and  over  again.  We  have 
to  come  up  with  a  top  down  approach  to  be  more 
efficient.  This  requires  bold  moves  and  the 
implementation  of  what  I  call  “wild  ideas”  as  shown  in 
figure  10.  May  be  some  of  those  ideas  are  not  so  wild 
at  all,  but  someone  has  to  take  the  lead,  and  this  cannot 
be  the  supplier  industry.  Again,  what  we  need  is  a  top 
down  approach. 


And  beyond  this? 
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Wild  Ideas.... 

.or  not  so  wild  at  all 

^  Cross  Corporation  Obsolescence  Management 

^  Joint  Purchasing  and  Warehousing 

^  Shared  Data  Warehouse 

^  Weapon  System  Coalitions  to  battle  Obsolescence  (e.g.. teaming 
of  F16,  C17,  B1-B,  JTIDS,  MILSTARS,  AWACS  and  JointSTARS 
in  the  USAF) 

^  Is  a  NATO  Obsolescence  Management  Organization  too  tong  a 
shot  ??? 

^  Can  we  get  help  somewhere  else,  use  the  experience  of  others? 

^  There  is  plenty  of  information  and  experience  out  there,  we  just 
have  to  go  get  it  (and  use  it). 

^  Who  is  taking  the  lead  ??? 


Figure  10  -  Wild  Ideas 

But  let  me  come  back  to  the  question  of  using 
commercial  components  in  military  equipment.  As  I 
have  outlined  already,  the  use  of  COTS  components  is  in 
my  opinion  no  way  to  mitigate  the  obsolescence 
problem,  since  COTS  is  subject  to  obsolescence  itself, 
and  as  we  are  all  aware,  life  cycles  are  shorter  and  the 
obsolescence  notification  process  is  less  disciplined.  No 
matter  what,  the  supplier  industry  will  be  forced  to  make 
more  and  more  use  of  commercial  components  simply 
because  of  the  continual  erosion  of  the  supply  base  of 
military  components.  We  will  have  to  deal  with  even 
more  difficult  obsolescence  problems  in  the  future.  In 
addition  it  must  be  said,  that  the  trend  towards 
commercial  components  is  not  limited  to  the  battle 
between  plastic  versus  ceramic  packages.  The  use  of 
COTS  components  in  military  applications  may  create 
an  additional  set  of  problems  in  the  future  which  may  for 
instance  be  attributed  to  the  consistently  shrinking 
structure  width  of  microcircuits  as  a  result  of  the  demand 
from  the  telecom  industry  and  the  trend  towards  zero 
volt  supply  voltage.  This  may  result  in  tremendous  EMC 
problems  for  our  equipment. 

But  isn’t  the  controversy  between  military  and 
commercial  a  controversy  between  extremes.  There  is 
not  only  black  and  white,  there  are  shades  of  gray  as 
well.  Within  the  last  10  years  QML  has  gained  a  lot  of 
attention  and  importance  within  the  defense  industry. 
Many  of  the  big  names,  who  dropped  out  of  the  military 
semiconductor  business,  have  certified  their  production 
lines  to  meet  the  QML  requirements.  Today  more  than 
30  semiconductor  manufacturers  have  qualified  more 
than  300  production  lines  and  the  trend  shows  a  stable 
growth.  In  short  QML  is  not  just  commercial,  but  is 
simply  better.  Actually  QML  is  best  commercial 
practice.  It  is  more  expensive  than  “commercial”,  but  is 
more  disciplined,  it  meets  most  of  our  stringent 
requirements  for  military  equipment  and  it  has  longer 
life  cycles.  However,  QML  is  vulnerable  to 
obsolescence  as  well,  and  the  use  of  QML  does  not  solve 
our  obsolescence  problem  either. 

And  here  comes  my  second  theorem,  which  is  rather 
trivial  again; 


Although  the  use  of  commercial  components  does  not 
help  to  mitigate  the  obsolescence  problem,  we  have  to 
use  them  anyway  to  mitigate  the  eroding  supply  base 
of  military  components. 


All  in  all  the  use  of  commercial  components  in  our 
military  systems  is  -  as  mentioned  before  -  still  a  big 
problem  in  itself.  It  requires  more  research,  diligence, 
cooperation,  and  a  lot  of  common  sense.  QML  may 
help  -  as  long  as  it  lasts. 

On  the  other  hand,  obsolescence  management  is  -  as 
we  have  all  become  painfully  aware  -  a  tremendous 
task  in  itself,  requiring  its  own  infrastructure  and 
resources.  And  it  has  to  be  done  regardless  of  the 
component  quality  level. 


Summary 

□  The  use  of  Industrial  Grade  Components  in  military 
equipment  will  become  a  necessity,  due  to  the 
diminishing  supply  base  for  military  components 

□  The  use  of  Industrial  Grade  Components  is  not  a  way 
to  mitigate  obsolescence  problems  ...  to  the  contrary 

□  The  use  of  Industrial  Grade  Components  is  an 
additional  challenge  to  obsolescence  management, 
which  has  to  be  accepted  by  the  industry. 


Figure  11  -  Summary 

In  summary  my  conclusion  is,  that  in  the  long  run  the 
use  of  commercial  components  in  our  systems  will 
become  a  necessity  but  for  other  reasons.  It  is  not  a 
way  to  mitigate  obsolescence,  it  is  an  additional 
challenge  to  obsolescence  management.  Still,  there  is 
no  other  way  than  to  accept  this  challenge,  since  our 
military  semiconductor  supply  base  will  continue  to 
erode. 
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Summary:  There  is  a  growing  discontinuity  between 
the  semiconductor  supply  chain  and  the  requirements 
of  military  programs  to  support  equipment  in  the  field 
for  long  periods  of  time  -  typically  for  15  years  or  even 
longer.  This  isn’t  news  any  more,  it  was  a  natural 
consequence  of  the  COTS  Procurement  Initiatives  and 
the  shift  in  focus  of  the  semiconductor  supply  industry, 
started  early  in  the  1990s,  to  much  larger  and  ever 
more  lucrative  markets.  While  COTS  was  embraced 
enthusiastically  at  the  outset  by  our  community,  some 
of  the  real  issues  are  only  now  beginning  to  come 
home  to  roost,  tainting  COTS  as  a  standard  for  doing 
business.  This  is  apparent  through  the  performance  of 
some  suppliers,  particularly  in  their  attitudes  and 
commitment  to  obsolescence  and  real  lifecycle 
management. 

This  paper  has  been  written  from  the  perspective  of  a 
COTS,  open  architecture,  board-level  supplier  and  is 
intended  to  provide  insight  and  guidance  for  the 
selection  and  management  of  a  supplier  when 
considering  various  options  of  overall  system  lifecycle 
management. 

COTS:  definition:  “Commercially  available  products, 
available  from  a  published  catalog  and  price  list.  The 
supplier  will  have  absorbed  the  IR&D  costs  and  will 
own  the  IPR.  Performance  of  the  product  is  as  stated 
in  the  supplier’s  specifications  ”.  This  pure  definition 
makes  no  claims  as  to  the  ruggedness  of  the  product, 
nor  to  its  suitability  for  deployment  in  the  final,  end- 
use  application.  The  integrator  must  make  the 
selection  of  product  and  supplier  based  on  his  own  and 
the  supplier’s  performance  specifications.  COTS 
procurement  is  not  descriptive  of  product  quality  or 
fitness  for  purpose,  it  is  a  process  which  must  be 
adopted  to  achieve  the  true  benefits  of  COTS. 

Program  Phases:  Systems  integrators  ideally  need  to 
maintain  technology  continuity  between  the  various 
phases  of  their  programs,  from  ATD  (Advanced 
Technology  Development),  through  EMD  (Engineering 
Manufacturing  Design),  LRIP  (Low  Rate  Initial 
Production)  and  Production.  COTS  products  such  as 
VME  have  had  a  real  and  visible  impact  on  reducing 


the  length  of  these  cycles,  particularly  for  non-mission 
critical  or  benign  environment  programs  where  the 
jump  has  been  made,  in  some  cases,  directly  from  ATD 
to  full  production  and  deployment.  However,  the  life  of 
individual  components  used  in  a  typical  VMEbus 
product,  often  as  short  as  18  to  24  months  today,  may 
not  be  long  enough  to  support  even  two  consecutive 
phases  of  program  development. 

Lifecycle  Management,  Early  Commitment  is 
Required:  Given  the  obsolescence  challenges,  total 
Product  Lifecycle  Management  is  the  only  way  to 
effectively  bridge  the  widening  gap  between 
customers’  and  end-users’  needs  and  our  industry’s 
ability  to  deliver  effective  and  maintainable  solutions. 
Lifecycle  management  is  just  what  it  says.  It  starts 
from  inception  of  a  new  product  idea  and  doesn’t  end 
until  the  last  customer  has  sent  his  last  product  back  for 
repair.  The  first  step  starts  with  new  product  design  by 
implementing  a  Component  Selection  Procedure.  This 
means  understanding  your  suppliers  and  their  market 
dynamics,  and  working  with  them  to  ensure  acceptable 
parts  longevity.  The  ideal  situation  is  to  only  deal  with 
suppliers  who  offer  a  reasonable  promise  of  longevity. 
Unfortunately,  this  is  not  always  practical  especially 
when  it  comes  to  the  leading-edge  technologies  that 
evolve  very  rapidly. 

At  this  stage  the  board  level  supplier  can  provide 
valuable  engineering  and  technical  input  during  the 
integrator’s  system  design  and  evaluation  process. 
There  are  usually  parts  of  a  system  that  are  fairly 
unique  to  the  platform  or  to  the  military  environment. 
Since  there  is  a  thriving,  though  small,  semiconductor 
supply  industry  still  serving,  for  example,  the  needs  of 
specific  military  interfaces,  it  is  unlikely  that  these 
areas  of  a  system  design  will  cause  severe 
obsolescence  problems  down  the  line.  The  vulnerable 
areas  of  a  system  design  are  those  that  feed  off  rapidly- 
evolving  technology  streams  such  as  those  driven  by 
the  desktop,  telecommunications  or  consumer  goods. 
Typically,  these  products  will  be  processors  (or  single 
board  computers),  graphics,  memory  and  DSP  boards. 
In  their  native  market  environments  these  technologies 
can  be  expected  to  have  life  spans  of  1  to  3  years.  This 
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is  unacceptable  for  the  15h-  year  lifecycles  of  major 
projects.  However,  these  technologies  are  setting  the 
standards  for  performance  and  functionality  and  have 
become  the  targets  for  new  and  innovative  approaches 
to  product  and  program  lifecycle  management. 

Lifecycle  Management,  Two  Options:  There  are  still 
only  2  basic  philosophies  for  program  lifecycle 
management.  These  can  usually  be  developed  into 
hybrids  if  necessary  to  suit  the  individual  program’s 
needs: 

Traditional:  Freezing  the  design  at  the  end  of  the  EMD 
phase  is  the  traditional  strategy  for  dealing  with 
continuity  of  design  and  obsolescence.  This  offers 
many  advantages  with  respect  to  control  and  total 
interchangeability  throughout  the  program  but  has 
serious  disadvantages  in  today’s  environment. 

Advantages: 

•  Total  design  control  is  achieved. 

•  Modules  of  a  like  kind  are  fully  interchangeable. 

•  The  performance  of  the  system  is  totally 
predictable. 

Disadvantages: 

•  The  design  is  fixed  and  therefore  inflexible  when 
the  time  comes  to  introduce  a  new  feature  or 
capability. 

•  Some  components  will  go  obsolete  between  the 
time  of  EMD,  LRIP  and  full  Production  with  no 
funding  source  available  for  their  procurement.  It 
is  unusual  for  funding  to  be  available  at  EMD  or 
LRIP  to  buy  the  full  program  lifecycle 
requirements  (5  year  production  plus  15  year 
support). 

•  Systematic  failure  of  one  single  part  can  make  the 
whole  system  vulnerable  to  its  effect. 

•  By  the  time  full  production  status  is  achieved  the 
technology  is  often  outdated  and  does  not  meet  the 
then  current  performance  standards. 

Traditional  long  term  program  support  requires  a 
Supplier  Program  Management  infrastructure  to  handle 
parts  control,  redesign  as  required  (either  device 
substitution,  replacement  with  ASIC  or  total  product 
redesign)  and  long  term  inventory  management. 
Tailored  lifetime  sustainment  programs  need  to  be 
created  to  meet  the  ongoing  needs  of  specific 
programs.  Despite  the  care  placed  upon  component 
management,  too  many  programs  are  getting  trapped 
into  maintenance  philosophies  that  are  at  the  mercy  of 
single-sourced  components,  many  of  which  are  already 
obsolete.  O&M  budgets  can  be  used  for  program 
sustainment  through  the  redesign  of  assemblies  using 
newer  parts  to  mitigate  against  obsolescence,  but  the 
wheel  will  inevitably  turn  again  and  no  advantage  is 
achieved  in  terms  of  either  enhanced  capability  or 
performance.  This  is  spending  just  to  stand  still  -  no 


improvement  in  the  performance  or  functionality  of  the 
equipment  will  be  gained  unless  a  major  redesign  is 
undertaken,  which  may  even  exceed  the  cost  of  the 
original  procurement. 

Technology  Insertion:  An  alternate  approach  that  is 
developing  into  an  industry  standard  is  Open 
Architecture,  Eunctional  Partitioning  and  Technology 
Insertion.  This  three-cornered  strategy  can  be  used  to 
define  the  future  lifecycle  requirements  of  a  system: 

Open  Architecture:  In  this  case,  based  on  the 
VMEbus,  but  could  be  CompactPCI  or  high  speed 
serial  architecture  such  as  Fibre  Channel  or  Firewire.  It 
provides  vendor  and  technology  independence  plus  a 
long-life  backbone  architecture  that  continues  to  evolve 
while  maintaining  backward  compatibility. 

Functional  Partitioning:  This  involves  the  designer’s 
use  of  the  modularity  afforded  by  the  chosen  open 
architecture  to  functionally  partition  the  system  into  a) 
platform-specifics  with  long  life  span  and  b) 
technologies  with  rapid  evolution  (i.e.  SBCs,  graphics, 
DSP  and  others). 

Technology  Insertion:  This  means  planning  to  insert 
improved  technology  in  batches  through  the  production 
and  support  life  of  the  program. 

Advantages: 

•  The  system  backbone  is  future-proofed  by  the 
extensive  commercial  interest  in  the  continued 
growth  and  development  of  VMEbus. 

•  The  system  can  be  upgraded  to  provide  greater 
performance  or  functionality  as  the  threat  changes 
(unlike  proprietary  systems  with  spare  slots  which 
always  proved  to  be  unusable  at  an  economic 
price)  and  finally  the  cost/performance  of  the 
system  will  improve  with  time. 

•  Moore’s  Law  will  prevail  meaning  that  the  cost  of 
each  new  generation  of  product  will  continue  to 
decrease. 

Disadvantages: 

•  Systems  built  in  batches  with  different 
configurations  will  present  some  additional 
logistics  overhead  in  record  keeping  and  inventory 

•  Recertification  of  safety-critical  functions  may  be 
required. 

This  is  the  model  that  many  of  today’s  integrators  are 
adopting  to  protect  against  future  obsolescence.  One 
example  is  Boeing/GDIS  (General  Dynamics 
Information  Systems)  and  the  OSCAR  (Open  Systems 
Core  Avionics  Requirement)  program  which  is 
planning  regular  insertions  of  increasingly  powerful 
Single  Board  Computers  (SBCs)  into  their  systems  for 
deployment  on  AV-8B,  E-15  and  E/A-18E/E. 
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Technology  Insertion  will  be  supported  by  many  COTS 
suppliers  in  future  generations  of  their  product  line 
evolution.  This  requires  serious  commitment  to 
continuously  update  and  replace  vulnerable  product 
lines.  This  is  very  different  to  the  single-point  solutions 
that  used  to  be  acceptable  for  the  traditional  controlled 
development  program. 

But  Technology  Insertion  cannot  just  happen.  Each 
new  program  should  evaluate  the  benefits  and  make 
plans  to  adopt  it  as  a  standard  from  the  outset: 

•  Make  control  loops  independent  of  processor 
performance. 

•  Never  hand-optimize  code  for  performance.  Make 
the  application  independent  of  hardware  specifics  - 
use  middleware  to  abstract  any  hardware  features. 

•  Further  abstraction  can  make  the  application 
independent  of  processor  type  -  will  require  an 
excess  of  performance  in  all  situations. 

•  Plan  for  the  use  of  the  increased  capability  offered 
by  technology  insertion. 

Program  Considerations:  The  lifecycle  management 
strategy  chosen  depends  upon  the  nature  of  the 
program:  the  size  of  the  production  run,  the  length  of 
the  full  production  cycle,  the  anticipated  lifespan,  the 
intended  maintenance  philosophy  and  so  on.  As  an 
example,  a  low  volume  program  with  a  relatively  short 
timespan  from  the  introduction  of  the  first  unit  to  the 
delivery  of  the  final  unit  can  often  live  within  the 
anticipated  product  lifecycle  of  the  chosen  supplier.  In 
this  case  it  is  likely  that  all  units  can  be  identical  and 
that  spares  for  the  deployed  lifetime  of  the  program  can 
be  procured  at  the  same  time  as  the  production  units. 
This  would  be  a  candidate  for  the  consideration  of  the 
traditional  methods  of  management.  But  the  downside 
must  not  be  ignored:  once  the  system  is  fielded  its 
functionality  and  performance  is  fixed  for  its  entire 
lifecycle,  no  ability  to  react  to  developing 
countermeasures,  or  changes  in  politics,  or  strategic 
redeployment. 

Consider,  however,  an  alternative  scenario  which  is 
typical  of  a  major  vetronics  (vehicle  electronics)  or 
avionics  procurement  program.  In  this  case  there  is 
often  a  lag  between  ATD,  LRIP  and  EMD  phase  as 
field  trials  and  exercises  are  used  to  shake  down  the 
final  performance  envelope  and  functional 
requirements.  A  typical  production  program  might 
encompass  1,000  vehicles  or  more  spread  over  a  15 
year  period.  Look  at  the  M1A2  Main  Battle  Tank, 
Eurofighter  Typhoon,  F-16  or  F/A-18  programs. 
Translate  that  into  buying  power,  for  example,  for 
microprocessors.  Even  if  each  platform  had  50 
processors  of  the  same  type  distributed  among  its 
various  subsystems,  that’s  only  5,000  pieces  per  year. 
Not  enough  to  capture  the  attention  of  today’s 
microprocessor  manufacturers. 


The  10  year  production  period  itself  is  incompatible 
with  today’s  fast  paced  technology  turnover:  the 
desktop  PC  is  barely  10  years  old  and  look  how  that 
has  changed.  This  is  a  prime  example  of  where  there 
has  to  be  a  series  of  technology  insertions  through  the 
production  life  just  to  ensure  continuity  of  supply.  In 
this  case  the  program  will  be  divided  into  a  number  of 
tranches  or  blocks,  each  representing  a  3  to  5  year 
production  standard.  Using  technology  insertion 
without  a  major  rewrite  and  recertification  of  the 
platform  at  each  step  is  the  obvious  solution  (see 
Figure  1).  Each  new  block  should  also  be  cheaper  than 
the  previous  -  driven  by  Moore’s  law. 

Technology  Refresh:  This  is  a  derivative  of 
Technology  Insertion.  In  the  previous  example  of  a 
large  production  program,  every  new  technology  step 
is  made  100%  backwardly  compatible  with  the 
previous  so  that  older  technology  can  be  refreshed  by 
swapping  out  the  old  for  new  whenever  maintenance 
action  allows.  Technology  refresh  requires  that  the 
supplier  is  very  strict  about  configuration  management 
to  guarantee  this  swap-out  capability  through  the 
inclusion  of  the  inevitable  minor  changes  over  a 
product’s  life. 

Future  Directions  for  COTS  Vendors:  Technology 
Insertion  is  the  strategy  that  COTS  suppliers  will 
support  through  future  generations  of  their  product 
lines.  This  requires  a  commitment  to  continuously 
update  and  replace.  There  is  a  very  big  difference 
between  program  lifecycles  and  COTS  product 
lifecycles.  A  COTS  product  has  a  lifecycle  much  like 
any  other  commercial  product  (i.e.  design  and 
development,  introduction  and  capture  of  design  wins, 
full-scale  production,  maturity  and  finally  retirement) 
but  with  extended  timescales. 

Product  Lifecycle  Planning:  COTS  suppliers  today 
must  preplan  their  products’  lifecycles  to  guard  against 
obsolescence  -  very  often  components  become 
obsolete  or  unobtainable  in  the  very  early  stages,  while 
the  product  is  still  capturing  new  design  wins.  Lifetime 
buys  are  often  the  only  way  to  guard  against 
obsolescence,  yet  how  can  the  supplier  estimate  the 
eventual  requirements  for  full  scale  production  and 
lifetime  support  this  early  in  the  cycle?  This  issue  was 
not  considered  seriously  enough  by  the  procuring 
authorities  in  the  changeover  to  COTS -based 
procurement.  COTS  products  will  go  obsolete  during 
the  development  timescales  of  a  program,  yet  there  is 
no  funding  provision  available  to  support  the  supply 
base.  The  only  way  for  the  supplier  to  protect  his 
investment  is  to  preplan  for  a  minimum  lifespan,  a 
minimum  production  volume  requirement  and  the 
introduction  of  a  replacement  product  (for  technology 
insertion)  as  early  as  possible.  In  this  way  the 
integrator  and  end-user  are  assured  of  a  continuous 
stream  of  evolving  yet  functionally  compatible 
products.  A  reasonable  timespan  today  for  a  ‘hot’ 
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product  is  5  years  from  design  and  development  to 
maturity. 

Programs  should  ideally  aim  to  be  in-phase  with  their 
chosen  supplier’s  product  lifecycle.  Suppliers  must 
advise  their  customers  of  a  product’s  relative  position 
on  its  lifecycle  curve  -  the  maximum  benefit  can  only 
be  obtained  when  full  scale  program  production 
coincides  with  full  scale  product  production.  Suppliers 
today  are  learning  to  share  these  product  lifecycle 
curves  and  their  future  roadmaps  with  their  customers 
to  everyone’s  benefit. 

COTS  product  lifecycle  management  is  still  very  much 
in  a  state  of  flux  and  only  part  of  the  way  up  the 


learning  curve.  Traditional  program  requirements 
cannot  be  abandoned  overnight,  so  the  ideal  is  to  be 
able  to  support  both  the  old  and  the  new  during  a  long 
period  of  transition.  Many  of  today’s  COTS  VME 
suppliers  do  not  appreciate  the  need  for  either  strategy, 
usually  following  technology  curves  with  little  regard 
for  the  program  lifecycle.  Even  though  the  root  cause 
of  rapid  component  obsolescence  is  outside  of  our 
direct  control,  there  is  much  that  can  be  done  in 
partnership,  between  supplier,  integrator  and  end-user 
to  mitigate  the  effects.  Reviewing  the  overall  system 
architecture  and  designing  for  Technology  Insertion, 
hardware  abstraction  and  program/product 
synchronism  hold  great  promise  as  methodologies  for 
the  future. 


Eigure  1 :  Cost  curve  of  large  program  based  on  regular  technology  insertion 
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Eigure  2:  Product  Lifecycle  curves 
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of  commercial  electronic  components  in  avionics 
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1.  SUMMARY 

The  time  when  aerospace  requirements  and  investments 
initiated  micro-electronic  components  development  has 
passed. 

Industries  like  Telecom  and  Personal  Computer  invest 
many  times  more  than  aerospace  with  huge  economical, 
performance,  size,  mass,  packaging  and  assembly 
improvements. 

The  lifespan  of  these  developments  in  the  market  is  very 
short. 

The  Life  Cycle  Costs  for  keeping  up  avionics  design  with 
special  ruggidised  components  and  designs  is  likely  to  be 
higher  than  to  adapt  a  military  aircraft  and  their  periphery 
to  avionics  with  non-ruggid  electronic  components. 

There  are  technical  solutions  available  to  adapt  the 
military  avionics  environment  to  the  requirements  of  non- 
ruggid  electronic  components  ad  designs. 

This  paper  describes  the  relevant  environmental  aspects  in 
nowadays  military  aircraft  designs,  which  have  to  be 
considered  and  their  relation  to  non-ruggid  electronics. 


a  extended  use  of  complete  off  the  shelf  HW  and 
SW  solutions, 

an  increase  of  cross-usability  of  HW  &  SW  in 
different  products  and  programmes, 
a  solution  for  the  obsolescence  difficulties  in 
military  programmes. 


3.  ACTUAL  ENVIROMNENTAL 

REQUIREMENTS  FOR  MILITARY  AVIONICS 

Following  examples  of  quantified  environmental 
requirements  are  actual  typical  for  military  avionics: 


Temperature:  Operating:  -  40°  to  h-70°C 

Non-Operating:  -  60°  to  h-90°C 
T-Changes:  up  to  40  K/s 

Supply  air:  -40°  to  h-54°C  with 

3.5kg/kW/min 


Pressure: 


3  to  1 15  kPaa 


Pressure  Changes: 


6  kPa/s  increasing 
4  kPa/s  decreasing 


Further  on  this  paper  describes  some  possible  .  . 

modifications  of  military  aircraft  designs  to  cope  with  the  Humidity, 
environmental  requirements  of  non-ruggid  electronics. 


absolute  0  to  30  gwATER/kgAm 
relative  0  to  100  % 


2.  ADVANTAGES  OF  USING  UNSCREENED 
ELECTRONIC  COMPONENTS  AND  DESIGNS 
INSIDE  A  MILITARY  AIRCRAFT 

The  immediate  and  unlimited  access  to  the  actual 
complete  electronic  market  with  its  very  fast  technological 
progress  of  electronic  components.  Printed  Circuit  Board 
layouts,  computer  architecture,  SW  design  and  IT  aspects 
allows: 


Sand  /  Dust:  up  to  20  g/m^ 

Vibration:  Functional:  uptoO.lOgVHz 

Endurance:  up  to  0.42  gVHz 

Frequencies:  10  to  2000  Hz 

Acceleration:  up  to  13  gn 

Acoustic  Noise:  up  to  150  dB 


a  fast  and  flexible  improvement  of  mission 
capabilities, 

an  avionics  mass  and  volume  reduction  (mission 
performance), 

an  avionics  upgrade  cost  reduction, 
an  avionics  Life  Cycle  Cost  reduction. 


EMC:  EMC:  >  200  V/m 

NEMP:  >  50  kV/m  in  ns,  50  A 

Lightning:  >  10  kA 


Power  Supply:  1 15/200  V  +  10%  ,  400  Hz  +  5% 
Power  Interrupts:  up  to  30  ms 


an  extended  competition, 

a  development  time  and  qualification  test  reduction. 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components”,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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4.  ACCEPTABLE  ENVIRONMENTAL 
CONDITIONS  FOR  NOT  RUGGID, 
UNSCREENED  CIVIL  ELECTRONIC 
COMPONENTS  AND  DESIGNS 

Following  examples  of  quantified  environmental 
conditions  are  accepted  by  not  ruggid,  unscreened  civil 
electronic  components  and  designs: 


*  Environmental  Control  System 

*  Electrical  Power  Generation  and  Distribution  System 

*  Data  Link 

*  Mechanical  Integration  (Aircraft  Structure,  Avionics 
Racks,  Module  Housing ) 

Eollowing  further  logistical  aspects  influence  the 
environment  of  the  military  avionics 


Temperature:  Operating:  H-10°  to  h-30°C 

Non-Operating:  0°  to  h-70°C 

T-Changes:  no  data  found 

Supply  air:  0°  to  h-55°C  with  1.5  m/s 


*  Handling  and  Maintenance  concept 

*  Testability  concept 

*  Storage  concept 

*  Aircraft  Ground  Equipment 


Pressure: 


70  to  llSkPaa 


5.2  ENVIRONMENTAL  RESPONSIBILITIES 


Pressure  Changes: 


no  data  found 


These  interfaces  and  aspects  influence  the  environmental 
conditions  of  the  military  avionics  in  the  following  ways: 


Humidity: 

absolute 

no  data  found 

relative 

0  to  50  % 

Sand  /  Dust: 

clean  environment 

Vibration: 

Functional: 

up  to  0.002  gVHz 

Endurance: 

no  data  found 

Frequencies: 

5  to  500  Hz 

Acceleration: 

up  to  4  gn 

The  Environmental  Control  System  influences  the 
Temperature,  Temperature  Changes,  Pressure,  Pressure 
Changes,  Humidity,  Contamination,  Fungus,  Salt  Fog, 
Sand  and  Dust  conditions  around  military  avionics  if 
electrical  power  is  available. 

The  Electrical  Power  Generation  and  Distribution  System 
influences  the  Electrical  Supply  and  EMC  conditions  for 
military  avionics. 

The  Data  Links  influence  also  the  EMC. 


Acoustic  Noise:  no  data  found 

EMC:  EMC:  3  V/m 

NEMP/Lighting:  no  data  found 

Power  Supply:  220  V  +  10%,  50  Hz  +  3% 

Power  Interrupts:  no  interrupts  accepted 

The  comparison  of  the  actual  military  environmental 
requirements  with  those  of  civil  electronic  components 
and  designs  show  significant  discrepancies. 

If  not-ruggid,  unscreened  civil  electronic  components  and 
designs  shall  be  used  inside  military  avionics,  the  military 
aircraft  has  to  be  adapted. 

5.  ADAPTATION  OF  MILITARY  AIRCRAFT 
TO  THE  NEEDS  OF  NOT-RUGGID, 
UNSCREENED  CIVIL  ELECTRONIC  IN 
MILITARY  AVIONIC 

5.1  MILITARY  AIRCRAFT  ASPECTS,  WHICH 
INFLUENCE  THE  ENVIRONMENTAL 
CONDITIONS  OF  MILITARY  AVIONICS 

Following  military  general  aircraft  systems  have  an 
interface  to  avionics  systems. 


The  Mechanical  Integration  of  avionics  into  the  military 
aircraft  influences  mainly  the  Vibration,  Acceleration, 
Shock,  Temperature,  Temperature  Change,  Pressure, 
Pressure  Change,  Humidity,  Contamination,  Fungus,  Salt 
Fog,  Sand,  Dust  and  EMC  conditions  of  these  avionics. 

The  Logistical  Aspects  like  ground  support,  maintenance, 
testing,  handling,  transport  and  storage  have  also  an  effect 
on  environmental  conditions  like  Vibration,  Acceleration, 
Shock,  Temperature,  Temperature  Changes,  Pressure, 
Pressure  Changes  and  Humidity. 

5.3  POSSIBLE  IMPROVEMENTS  OF  THE 

ENVIRONMENTAL  CONDITIONS  FOR  THE 
MILITARY  AVIONICS 

In  this  chapter  some  examples  will  be  described  how  the 
environmental  conditions  for  the  military  avionics  can  be 
improved: 

5.3.1  ENVIRONMENTAL  CONTROL  SYSTEM 

Most  of  the  actual  produced  military  aircraft  use  an 
Environmental  Control  System  (ECS)  based  on  an  engine 
bleed  air,  bootstrap,  open  air  cycle  and  emergency/ground 
fan  air  supply  concept. 

The  basics  of  this  technology  were  developed  nearly  half 
a  century  ago  and  fit  at  this  time  quite  well  in  the  overall 
aircraft  concept.  Although  the  efficiency  of  this  concept  is 
very  low,  requires  a  lot  of  engine  trust,  causing  high 
aerodynamic  drag,  radar  reflections  and  additional 
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infrared  signatures  as  well  as  high  temperature  /  high 
pressure  air  leakage  risks,  it  seems  to  be  relatively  reliable 
and  light. 

This  concept  provides  the  military  avionics  during  aircraft 
ground  and  main  ECS  failure  conditions  with  unfiltered 
and  unconditioned  aircraft  ambient  air  and  during  normal 
ECS  operation  with  unfiltered,  partly  dehumidified  engine 
or  Auxiliary  Power  Unit  (APU)  bleed  air. 

To  keep  the  above  mentioned,  significant  disadvantages 
as  low  as  possible,  these  type  of  ECS  were  designed  to 
provide  just  an  environment  which  allows  high  ruggidised 
military  avionics  to  survive. 

New  technologies,  in  development  by  EADS  Military 
Aircraft  Business  Unit  in  Germany,  would  allow  to  design 
an  electrical  driven,  fuel  cooled,  closed  loop  vapour  cycle 
system  with  much  higher  efficiency,  lower  aerodynamic 
drag,  lower  signatures,  but  equivalent  reliability  and  mass. 

This  concept  allows  significant  improved  avionics 
conditioning,  regarding  Temperature,  Temperature 
Changes,  Pressure,  Pressure  Changes,  Humidity, 
Contamination,  Fungus,  Salt  Fog,  Sand  and  Dust,  on 
ground,  in  flight  and  in  most  of  the  emergency  cases. 

5.3.2  ELECTROMAGNETIC  COMPATIBILITY 
(EMC) 

A  survey  of  the  Electromagnetic  Compatibility  (EMC) 
problems  to  be  solved  for  military  systems/equipment  is 
presented  in  figure  1 . 

As  an  absolute  preposition  the  “Internal  EMC”  has  to  be 
guaranteed  between  all  electrical/electronic  components 
installed.  Care  has  to  be  taken  about  unwanted  radiated 
and  conductive  coupling  between  the  different 
components. 

Equipment,  which  will  be  integrated  into  a  system,  has  to 
fulfil  “Intra-System  EMC”-requirements.  Unwanted 
emissions  have  to  be  limited  to  tolerable  levels.  Certain 
immunities  are  required  to  avoid  interference  caused  by 
other  equipment.  Radiated  coupling  paths  have  to  be 
considered  as  well  as  conductive  ones.  Different  types  of 
signals  must  be  taken  into  consideration  starting  at  short 
time  duration  pulses  up  to  continuous  wave  signals. 

Most  systems  have  to  operate  in  a  certain  electromagnetic 
field  strength  environment,  which  might  be  generated  by 
the  transmitters  of  other  systems  or  also  by  external 
broadcast  or  radar  transmitters.  “Inter-System  EMC”  has 
to  be  achieved  in  such  a  case.  -  The  environment 
requirements  might  reach  several  100  V/m  up  to  several 
kV/m  in  the  case  of  an  aircraft.  Simple  commercial 
equipment  like  e.g.  computers  have  to  be  protected 
against  an  environment  up  to  3  V/m  only.  -  The 
electromagnetic  environment  might  affect  the  electrical 
components  either  by  penetrating  the  equipment  case 
or/and  by  inducing  currents  on  the  power  and  signal  lines. 
Many  equipment  have  to  be  protected  against  lightning 
strikes.  “Direct  Effects”  caused  by  direct  lightning  hits 
might  not  be  of  interest  in  the  most  cases.  The  “Indirect 
Effects”  of  lightning,  however,  have  to  be  considered. 
Significant  currents  can  be  induced  in  the  power  and 


signal  lines.  In  the  aircraft  e.g.  levels  up  to  several  kA  can 
have  been  measured.  Similar  amplitudes  can  be  expected 
for  equipment  installed  in  buildings. 

The  “Nuclear  Electromagnetic  Pulse”  (NEMP)  has  to  be 
considered  as  a  problem,  too,  for  many  military 
systems/equipment.  The  threat  level  is  defined  as  50 
kV/m  with  a  rise  time  of  a  few  ns.  The  NEMP  might 
affect  the  electronic  components  in  the  equipment  via  the 
currents  induced  in  the  lines  and  via  the  fields  penetrating 
directly  through  equipment  case. 

Eor  a  selected  group  of  systems/equipment  TEMPEST  is 
required.  If  classified  information  is  handled  in  a  system, 
it  has  to  be  avoided,  that  the  non-encoded  electrical 
signals  radiate  to  the  outside. 

TREE  =  “Transient  Radiation  Effects  on  Electronic”  does 
not  belong  directly  to  the  electromagnetic  effects.  It  has, 
however,  to  be  considered  in  this  context,  too. 
Interference  or  also  damage  can  be  caused  in  electrical 
circuits  by  nuclear  radiation  directly  affecting  the 
semiconductor  components. 

Comparison  Between  Military  and  Commercial 
Requirements 

Table  2  presents  a  survey  about  the  military  and 
commercial  requirements  on  equipment/systems. 

“Internal  EMC”  between  all  components  installed  within 
an  equipment  is  absolutely  required  in  both  cases.  There  is 
not  a  real  difference  between  both  sides.  Solutions  can  be 
realised  by  e.g.  a  good  EMC-design  of  the  Printed  Circuit 
Boards  (PCB's)  and  a  good  de-coupling  between  the 
PCB's  in  the  case  (“arrangement,  special  internal 
shielding,  etc.). 

“Intra-System  EMC”  is  not  too  much  different  between 
the  commercial  and  the  military  side,  too.  Although 
different  specifications  are  applied  in  the  commercial  and 
the  military  world  including  different  procedures  and 
limits,  the  problems  are  comparable. 

“Inter-System  EMC”  has  to  cover  generally  significantly 
higher  environment  requirements  in  the  case  of  military 
applications.  That  means,  higher  field  strength  levels  have 
to  be  considered  penetrating  equipment  cases  and  higher 
currents  induced  on  cabling.  Additional  protection  is 
required. 

The  problems  of  “Indirect  Effects  of  Lightning”  are 
similar  for  military  and  commercial  equipment/systems. 
The  NEMP  is  a  threat,  which  is  mainly  considered  for 
military  systems/equipment  only.  The  equipment  will  be 
affected  via  the  same  coupling  paths  like  considered  for 
the  “Inter-System  EMC”.  High  amplitude  field  pulses 
might  penetrate  via  the  equipment  cases.  High  currents 
(“damped  sinusoidal  signals”)  might  be  induced  on  the 
lines.  Additional  protection  is  required. 

TEMPEST  is  only  applicable  for  selected  military 
systems/equipment.  Emissions  caused  by  the  non-encoded 
classified  signals  have  to  be  controlled  very  carefully  by 
measures  within  and  outside  the  equipment.  Significant 
additional  protection  measures  are  required. 

TREE  is  also  applicable  for  some  selected  military 
systems/equipment  only.  Some  protection  measures  can 
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be  realised  by  circuit  design,  but  in  general  special 
hardened  components  should  be  required. 

Survey  of  Additional  Protection  Measures  Required 

Commercial  components  can  be  considered  to  have  very 
similar  EMC  properties  (emissions  and  susceptibility  to 
interference  signals)  like  the  military  ones.  The  only 
exception  is  TREE.  Commercial  components  should 
generally  be  weaker,  because  hardening  against  nuclear 
radiation  requires  a  component  special  design.  In  addition 
the  relevant  hardening  data  are  not  available  for  the 
commercial  components. 

The  consequences  for  application  of  commercial 
components  in  military  equipment/sy stems  are  : 

If  TREE  requirements  exist,  commercial  components 
might  cause  problems.  A  lot  of  statistical  test  data  have  to 
be  collected  to  get  sufficient  confidence  about  the 
hardening  level  and  to  demonstrate  sufficient  protection. 

If  commercial  components  shall  be  applied  in  all  other 
systems/equipment,  there  should  not  be  any  problem,  if 
the  EMC  design  of  the  equipment/sy  stem  follows  the 
usual  military  guidelines. 

Designing  the  equipment/sy  stems  following  the 
commercial  rules  only,  has  to  be  considered  to  be  not 
sufficient.  To  cover  especially  the  additional  “Inter- 
System  EMC”-  and  NEMP-aspects,  the  following 
additional  protection  measures  are  required  (figure  3) : 

•  Improvement  of  shielding  of  the  equipment  case 
against  “Inter-System  EMC”  -  and  NEMP  -  fields  to 
be  achieved  by  : 

-  Good  electrical  sealing  between  cover  and  case  and 
different  parts  of  the  case 

-  Grounding  of  all  mechanical  introductions  (e.g.  also 
wave  guides)directly  to  equipment  case 

-  Eiltering  of  all  unshielded  wires  (e.g.  power  lines) 
running  into  the  case 

-  Avoidance/reduction  of  openings  respectively 
replacement  of  large  openings  by  a  lot  of  smaller 
ones 

•  Additional  interface  protection  measures  against 
“Inter-System  EMC”-  and  NEMP  induced  currents 
Eilters  will  help  to  reduce  the  CW-signals,  suppressor 
diodes  to  reduce  the  NEMP  induced  signals 

•  Additional  cable  shielding  against  the  “Inter-System 
EMC”-  and  NEMP  induced  currents 

A  single  cable  shield,  e.g.  will  reduce  the  induced 
currents  by  a  factor  of  at  least  10 

TEMPEST  might  require  more  intensive  protection  than 
“Inter-System  EMC”  and  NEMP.  This,  however,  can  also 
be  realised  on  circuit  design-,  equipment  case-  and 
cabling  level  and  does  not  exclude  the  application  of 
commercial  components. 

5.3.3  VIBRATION 

Avionics  in  actual  military  aircraft  has  to  cope  with  a 
relative  high  vibration  load,  which  is  critical  for  the 
sensitive  commercial  electronic  and  optical  components. 


A  fixed  installation  of  an  avionics  box  would  guarantee 
stable  position  of  the  box,  but  all  occurring  vibrations 
would  be  transferred  directly  and  unlimited  to  the 
sensitive  components. 

A  soft  installation  on  passive  vibration  dampers,  like 
shock  absorbers,  would  reduce  the  vibration  loads,  but 
with  high  frequency  damping  the  amplitude  of  movement 
due  to  resonant  frequencies  would  increase. 

A  combination  of  passive  vibration  dampers  for  high 
frequencies  with  an  active,  adaptive  damping  for  low 
frequencies  showed  significant  reduction  of  vibration 
loads  on  avionics  boxes  (see  figure  4). 

The  active  and  adaptive  dampers  -  e.g.  two-axis, 
electromagnetic  linear  motors  -  induce  forces  with  180° 
phase-shift  (see  figure  5)  to  the  vibration  loads,  which 
lead  to  a  reduction  of  the  amplitudes. 

6.  RESUME 

The  military  aircraft  would  profit  from  an  unlimited 
application  of  unscreened,  not-ruggid  electronic 
components  and  design.  The  environment  inside  a 
military  aircraft  has  to  be  improved  to  allow  reliable  use 
of  these  components  and  design.  There  are  technical 
solutions  available  to  fulfil  the  environmental 
requirements  of  these  components  and  designs. 
Experimental  studies  would  help  to  prove  this  new 
concept. 

7.  ABBREVIATIONS 

A  Ampere 

APU  Auxiliary  Power  Unit 

COTS  Commercial  Off  The  Shelf 

CW 

EADS  European  Aeronautics,  Defense  and  Space 
Company 

ECS  Environmental  Control  System 

EMC  Electromagnetic  Compatibility 

g  Gravitational  Force  [9.81  m/s^] 

HW  Hardware 

IMA  Integrated  Modular  Avionics 

IT  Information  Technology 

JTA  Joint  Technical  Architecture 

kA  Kilo-Ampere 

kPa  Kilo-Pascal 

kV  Kilo-Volt 

LCC  Life  Cycle  Costs 

m  Meter 

MABU  Military  Aircraft  Business  Unit 

NEMP  Nuclear  Electromagnetic  Pulse 

p  Pressure  [kPa] 

PCB  Printed  Circuit  Board 

SW  Software 

T  Temperature  [°C] 

TREE  Transient  Radiation  Effects  on  Electronic 

V  Volt 
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Fig.  1 :  Survey  of  EMC  Requirements  for  Military  Equipment/Systems 
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Other  specifications;  similar  problems 

Inter-System  EMC 

Yes 

Yes 

In  general  significantly  higher  requirements  on 
military  side;  additional  protection  required  : 

Case  shielding;  interface  protection  :  filters,  cable 
shielding) 

Lightning  Protection 
(Indirect  Effects) 

Yes 
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Similar  problems  to  be  solved 

NEMP 
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TREE 
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No 

Additional  protection  measures  required;  circuit  design 
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required 

Fig.  2 :  Comparison  of  Requirements  for  Military  and  Commercial  Application 
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Fig.  4  Active  and  Adaptive  Vibration  Dampers: 
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COTS  in  our  Air  Control  System 
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1  Abstract 

A  huge  international  project  was  launched 
in  1997  in  Hungary:  setting  up  an  air  control  and 
sovereignty  nationwide  system  based  on  former 
Soviet  radars  and  American  air  sovereignty  operations 
centre  (ASOC). 

The  deadline  was  extremely  short  and  the 
available  funds  low.  The  main  strategy  of  the  project 
was  to  use  modular  elements  and  commercial 
components  as  much  as  possible. 

That  is  why  we  decided  using  PC-s  (dual 
Pentium  II  class),  Windows  NT  4.0  operating  system 
and  Visual  C-H-  developer  system.  Some  part  of 
hardware  were  developed  using  digital  signal 
processors  (TEXAS  type).  Our  specialists  and 
American  collages  worked  hard  and  the  American 
made  ASOC  centre  and  the  Hungarian  information 
system  were  used  for  military  service  in  the  fourth 
quarter  of  1998.  The  system  transmitted  the  radar 
(military  and  civil,  primer  and  secondary)  information 
automatically  to  ASOC  in  real  time. 

2  Antecedents  of  starting  the  program 

In  January  of  1994  President  Clinton 
suggested  building-up  a  collective  regional  air  control 
and  sovereignty  system  covering  four  countries  as  an 
integral  part  of  “Partnership  for  Peace”  program  on 
the  summit  conference  of  Visegrad  countries,  in 
Prague. 

In  January  of  1995  the  US  Deputy  Minister 
of  Defense  stated  in  Trencin  (Slovakia)  that,  his 
government  had  accepted  building  up  the  system  (it 
means  6.25  million  USD  for  Hungary)  after 
accomplishment  of  appropriate  conditions.  The 
Hungarian  government  accepted  the  proposal  of  USA 
government  (building  up  ASOC  in  Hungary)  and 
introduced  to  the  Parliament  for  approval  a  resolution. 

In  September  of  1995  The  Parliament 
adopted  a  resolution  (94/1995.  OGY),  developing  of 
information  and  control  radar  system. 

The  Government  of  the  Hungarian 
Republic  agreed  with  the  necessity  of  developing  of 
information  and  control  radar  system,  and  assisted 
that  Ministry  of  Defense  to  start  development  and 
procurement  program  of  modem  technical  equipment 
for  this  action  by  international  application. 

The  inter-governmental  agreement  about 
deployment  of  ASOC  in  Hungary  (LOA)  was  signed 
at  the  end  of  1996. 


3  Antecedents  of  developing  of  air-defense 

information  system  serving  Hungarian  ASOC 

The  American-Hungarian  professional 
conference  defining  connection  of  information 
sources  to  ASOC  took  place  in  July  of  1997.  In  third 
quarter  of  1997  establishment  of  ASOC  home 
conditions  could  start.  It  was  necessary  to  develop 
modern  equipment  agreed  actual  demands  applying 
and  modifying  former  developments’  results, 
regarding  actually  measuring  reports.  The  document 
named  “Data  sheet  and  basic  requirements”  was 
agreed  on  30-th  July  in  1997.  The  Automation  and 
Radar  Department  in  the  Institute  of  Military 
Technology  prepared  the  “tactical-technical 
requirements”,  which  contained  Hungarian 
requirements.  It  is  the  first  nation-wide  system 
developed  in  International  Co-operation. 

For  the  proper  operation  of  ASOC  there 
was  necessary  radar  information  in  plot-  or  track  form 
to  transfer  in  a  defined  protocol.  There  were  many 
tasks  in  researching  and  developing  (R&D)  plan  of 
the  Institute  of  Military  Technology  falling  on 
developing  all  system  of  military  radar  technology. 
Institute  of  Military  Technology  with  civilian 
companies  had  many  results  in  these  developing 
tasks,  but  deploying  ASOC  system  in  Hungary  had 
many  new  aspects  of  problems  in  communication 
protocol  interface  to  the  new  centre. 

3.1  What  kinds  of  tasks  had  co-operative  partners! 

3.1.1  Tasks  of  the  USA  partner 

-  Deploying  ASOC  center  (hardware, 
software)  in  Veszprem; 

-  Providing  conditions  for  integrating 
Hungarian  developed  systems. 

3.1.2  Tasks  of  the  Hungarian  partner 

-  Provide  facilities  for  deployment  of 
ASOC  (room,  communication,  power 
supply); 

-  Provide  communication  systems  for 
ASOC; 

-  Provide  digitizer  information  sources 
(radar’,  flight  plan); 

-  Getting  air  picture  information  by  ASOC 
to  users; 

-  Co-operation  in  integration  of  Hungarian 
developed  equipment  to  ASOC  system, 
together  with  domestic  civilian 
companies. 
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4  The  tasks  of  the  ASOC  and  the  connected  air 
traffic  control  system  that  was  made  according 
to  the  Hungarian  Military  Research  and 
Development  (R&D) 

-  Assuring  the  air  sovereignty  of  the 
independent  Hungarian  Republic; 

-  Gathering  information  about  the  objects 
in  the  national  air  space  (reconnaissance 
of  the  air  targets  and  measure  their 
location  with  radar’s); 

-  Pre-processing  of  radar  data  for 
transmission  (digitalisation,  conversion  of 
computer  protocols); 


-  Providing  the  radar  data  for  processing 
(sector  center  functions); 

-  Analysis  and  decision  preparation 
(function  that  helps  for  the  commander  at 
the  sector  centre  and  the  regional  air 
sovereignty  control  centre) 

-  Transmission  of  target  identifier  to  the 
active  arms  (transmission  of  the 
commands  to  the  subordinates  with 
displaying  on  the  computer). 


4.1  Radar  information  system  before  ASOC 


radar 


subunit  plotting 
board 


informant  plotting 
board 


operator 
cp,  r,h,t 


r 

1 

1 

active  arms  p  otting 
board 
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Before  setting  up  ASOC  the  information  from  radar  site 
to  the  active  arms  was  translated  via  voice. 

It  means  that  some  soldiers  dictated  the  data  of  flaying 
objects,  others  drew  them  on  the  plotting  board. 

The  information  flow  was  not  too  accurate,  and  was 
delayed  3-6  minute. 

4.2  The  national  system 's  grouping  by  the  tasks 
Providing  the  different  radars  as  information  source 

-  Civil  radars  (long-range  radar  and  short- 
range  radar),  primary  and  secondary  plot 
information  transmission  to  the  ASOC; 

-  Military  radar’s'  primary  and  secondary 
plot  information  transmission  to  the 
ASOC; 

-  Flight  data  plan  (civil  and  military) 
transmission  to  the  ASOC. 

Accept  the  air  traffic  picture  made  by  the  ASOC 

-  Displaying  the  air  position  at  the  active 
arms; 

-  Transmission  the  target  identifying 
directive  of  the  commander's. 

Providing  the  communication  with  common  protocol 

We  signed  a  contract  with  Hungarian 
developer  enterprises  according  to  the  Public  Purchase 
Law. 

These  were  the  seven  developing  tasks; 

1 .  ARE  -  Automatic  Radar  Extractor 
(converter  that  makes  digital 
sign  from  the  radar  video  sign) 

5  Essential  components  of  the  system 


2. 

RHP 

-  Radar  head  processor  (tracker 
instrument) 

3. 

RICK 

-  Radar  Information  Collecting 
and  Processing  Sub-centre 

4. 

EPDI 

-  Plight  Plan  Data  Interface 

5. 

CTCI 

-  Civil  Air  Traffic  Radar  Data 
Control  Interface 

6. 

KRI 

-  Communication  System 
Interface 

7. 

TAR 

-  Information  Sub-centre 

The  Hungarian  developed  air  traffic  control 
system  connected  to  ASOC  is  finished.  Under  the 
control  of  the  Ministry  of  Defense  Institute  of  the 
Military  Technology  the  Hungarian  companies 
designed,  manufactured  and  measured  the  necessary 
hardware  and  software.  The  system  has  been  installed 
at  14  locations  according  the  contracts.  Eield  test 
started  at  1998  August  and  finished  in  1998  October, 
parallel  with  the  American  partner  installed  the  ASOC 
centre  at  Veszprem.  The  final  application  program's 
installation  and  integration  to  the  national  air 
sovereignty  control  system  was  carried  out  in  1998 
August.  American  made  ASOC  center  and  the 
Hungarian  information  system  in  use  for  military 
service  from  the  fourth  quarter  of  1998.  The  system 
transmitted  the  radar  (military  and  civil,  primer  and 
secondary)  information  automatically  to  ASOC  in  real 
time. 
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5.1  Automatic  radar  extractor  (ARE) 

It  is  a  basic  part  connected  to  the 
Hungarian  Air  Sovereignty  Operations  Center  by 
means  of  Radar  head  processor  (RHP).  By  digitising 
and  transmitting  the  positions  of  flying  objects  in  the 
air  it  gives  the  primary  military  radar  information  to 
the  ASOC. 

5.2  Radar  head  processor  (RHP) 

The  function  of  the  RHP  (tracker 
computer)  acceps  secondary  radar  plots  and  the 
primary  plots  coming  from  Hughes  primary  radar 
extractor.  The  RHP  accepts  military  radar  plots 
processed  by  the  ARE  at  air  sovereignty  control  sites 
where  there  is  no  IFF  device.  The  RHP  makes  tracks 
from  the  primary  and  secondary  plots  and  unifies  the 
tracks  belonging  to  the  same  target  (correlation).  The 
device  sends  the  secondary  plot  directly  to  the  ASOC. 
One  can  make  a  choice  between  the  transmission 
primary  plots  directly  to  the  ASOC  or  send  track 
transmission  to  the  ’’Radar  Information  Gathering  and 
Processing  Subcenter”  (RICK). 

5.3  Radar  Information  Gathering  and  Processing 
Subcenter  (RICK) 

It  supplies  the  ASOC  system  with  qualified 
radar  (track)  information.  It  is  suited  to  work  out 
integrated  air  traffic  picture  based  on  RHP  track  data. 
Operators  are  able  to  provide  manual  or  automatic 
aircraft’s  identification.  It  supports  computer-aided 
control  and  identification  of  civil  public  flights. 

5.4  Flight  Planing  Data  Interface  (FPDI) 

It  provides  the  flight  plan  data  from 
“Automated  flight  planning  system”  (ARTR-II)  to 
ASOC  in  a  protocol  defined  in  the  “ASOC  -Interface 
Design  Document”  (IDD). 

5.5  Civil  Air  Traffic  Radar  DATA  Control  Interface 
(CTCI) 

The  CTCIs  function  is  the  transmission  of 
three  digitised  civil  radar  data  to  the  ASOC.  It  is  also 
a  radar  source  for  ASOC  to  the  creation  the 
continuous  real-time  air  traffic  picture. 

The  second  function  of  the  CTCI  is  the 
conversion  of  the  radar  information  from  coming  the 
protocol  defined  MATIAS  Interface  Control 
Document  (ICD)  (AFENIA  HDFC  protocol, 
ASTERIX  form)  to  the  protocol  defined  in  the 
“ASOC  ICD”. 

5.6  Communication  System  Interface  with  the 
Demarcation  Panel  (KRI) 

It  provides  the  communication  of  the 
national  developed  information  system,  to  the  data 
transfer  from  Hungarian  information  sources  to  the 
demarcation  panel.  The  communication  system 
provides  data  exchange  between  the  national 
information  sources  (Radar  Head  Processors,  civilian 
radar’s.  Radar  Information  Gathering  and  Processing 
Subcenter)  and  Hungarian  ASOC  using  “Radar  Data 


Multifunction  Transmission”  (RAMA-2)  protocol.  It 
also  provides  data  exchange  between  foreign 
information  sources  (neighbouring  ASOCs,  NATO 
centres,  military  radar  information  of  neighbouring 
countries)  and  Hungarian  ASOC.  It  provides  the 
protocol  checking  of  communication  and  physical 
connection  capability  for  the  information  system  as 
well. 

5.7  Information  Subsystem  (TAR) 

At  the  Operations  Centre  of  Air  Force  Staff 
the  ASOC  air  traffic  picture  is  distributed  from  the 
ASOC  output,  and  is  sent  target  designation  to 
fighters  and  air  defence  missile  troops’  headquarters 
by  TAR. 

6  ASOC  tasks 

The  ASOC  is  an  air-picture  displaying 
system  based  on  the  radar  data  of  home  digital  or 
digitised  2D  or  3D  radars.  The  system-input  sources 
reviewed  previously.  We  had  to  do  the  fitting  of  the 
data  transmission  protocol  at  input  sources  in  all 
cases.  Furthermore  the  Fink-1  connection  was 
important,  which  through  we  can  be  in  contact  with 
the  airspace  control  centre  of  NATO.  The  ASOC  has 
to  take  over  the  former  obsolete  manual  displaying 
and  controlling.  The  system  is  capable  of  providing 
the  airspace  control  at  peacetime,  however  it  gives  an 
opportunity  of  the  later  enlargement  by  defense 
functions. 

7  Strategy  of  project 

When  Institute  of  Military  Technology 
started  the  project  two  things  were  clear:  we  had 
extremely  short  deadline  and  very  low  available 
material  founds.  To  solve  the  problem  we  worked 
very  hard.  We  decided  to  use  all  results  we  reached  in 
the  last  five  years  in  this  field,  and  built  up  modular 
system..  At  the  end  approximately  80%  of  all  systems 
was  built  up  in  commercial  components.  We  used  PC- 
s  (dual  Pentium  II  266Mhz),  Windows  NT  4.0 
operating  system  and  Visual  C-n-  developer  system. 

8  Operating  experience 

The  nation-wide  system  has  been  working 
for  2  years.  The  system  consists  of  more  than  20  PC- 
s,  and  operates  for  24  hours/day. 

There  were  19  hardware  and  8  software 
failure  in  this  year. 

Most  of  the  problems  were  caused  by  the 
uninterruptible  power  source. 

Feast  of  the  problems  were  caused  by  the 
monitors.  Monitor  problem  occurred  only  once  in  two 
years. 

The  ASOC  system  with  the  domestic 
developed  input  and  output  equipment  change  the 
obsolete  airspace  control  system.  Nowadays  it  is 
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impossible  to  control  the  huge  amount  of  aircrafts 
crossing  our  airspace. 

The  problems  have  been  solved  by  the  real 
time  digital  equipment.  The  reliability  of  the  system  is 
determined  by  reliability  of  our  radars  and 
communication  lines,  therefore  we  have  to  improve 
the  system  at  these  fields. 
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1.0  INTRODUCTION 

Due  to  the  rising  costs  of  today’s  weapon  systems,  the 
U.S.  Department  of  Defense  (DOD)  continues  to 
implement  strategies  to  reform  its  acquisition  and 
procurement  process.  One  such  strategy  seeks  to 
reduce  the  cost  of  developing  systems  by  purchasing 
commercial  off-the-shelf  (COTS)  technology.  The 
COTS  technology  ranges  from  components  used  to 
build  a  particular  weapon  system  to  functional  pieces 
of  gear  used  to  support  the  weapon  system,  i.e.,  support 
equipment.  The  COTS  technology  may  be  instituted  at 
the  inception  of  the  weapon  system  design  or  it  may  be 
inserted  into  the  support  of  the  weapon  system  at  any 
point  during  its  life  cycle.  The  COTS  technology  is 
intended  to  reduce  weapon  system  life-cycle  costs  by 
minimizing  the  expense  of  system  design  and  testing. 

While  using  COTS  technology  is  beneficial  to  the 
DOD,  several  factors  must  be  weighed  before  such 
technologies  can  be  introduced  effectively.  Above  all, 
the  typical  systems  engineering  thought  process  must 
be  adjusted  to  incorporate  the  potential  risks  of  COTS 
technology.  One  of  the  most  significant  risks  involves 
parts  obsolescence.  Systems  engineers  must  decide 
how  and  when  to  use  rapidly  changing  COTS 
technology  to  keep  pace  with  the  commercial 
technology  market.  Technology  manufacturers 
regularly  develop  new  versions  of  electronics  and 
software  and  new  designs  of  mechanical  parts.  These 
rapid  changes  lead  to  technology  “outpacing”  fielded 
military  systems,  which  often  have  long  life  spans  and 
require  legacy  parts  support.  Previously,  as  one  of  the 
most  influential  players  in  the  development  of 
technologies  such  as  electronics,  the  DOD  often 
“drove”  technology  development  to  fulfill  its  needs. 
Now,  increasing  demands  for  electronic  technologies 
from  all  sectors  of  the  market  (e.g.,  industrial, 
professional,  personal,  and  government)  have  lessened 
the  DOD’s  influence  on  the  pace  of  technology 
development.  And,  while  the  DOD’s  desire  to  field 
new  and  innovative  technologies  has  increased. 


acquisition  budgets  have  actually  decreased.  As  a 
result,  the  DOD  finds  it  more  difficult  to  drive  major 
price  efficiencies  than  in  the  past.  Because  the 
commercial  industry  currently  views  the  DOD  as  a 
different  kind  of  player  in  the  technology  market — one 
with  more  stringent  requirements  than  other 
customers — the  DOD  no  longer  can  easily  influence 
technology  suppliers  to  design,  test,  and  support  their 
products  in  the  manner  prescribed  by  the  DOD.  In 
short,  technology  suppliers  are  less  willing  to  guarantee 
the  configuration  design  stability  and  logistics  support 
required  by  DOD  systems  engineers  to  ensure  that  a 
weapon  system  will  be  adequately  supported 
throughout  its  life  cycle.  This  diminished  technology 
support,  if  not  managed  properly,  can  lead  to  parts 
obsolescence,  which  in  turn  can  lead  to  increased  life- 
cycle  costs  for  a  weapon  system,  as  well  as  diminished 
mission  readiness. 

For  example,  there  is  an  inherent  risk  if  the  DOD 
procures  COTS  equipment  for  a  specific  weapon 
system  and  the  technology  manufacturer  ceases  to 
provide  replacement  parts  because  technology  has 
advanced  since  that  equipment  was  fielded.  In  the  best- 
case  scenario,  the  manufacturer  designed  its  equipment 
using  open  architecture  and  either  the  new,  updated 
technology  parts  can  directly  replace  the  old  parts  in 
the  fielded  equipment  or  they  can  be  integrated  using  a 
manufacturer-supplied  interface.  In  the  worst-case 
scenario,  replacement  parts  are  not  available  because 
the  manufacturer  has  either  gone  out  of  business  or  did 
not  plan  to  supply  upgraded  or  original  parts  to  the 
DOD  over  the  lifetime  of  the  weapon  system.  In  either 
case,  the  DOD  will  have  to  cover  the  risk  to  mission 
readiness,  as  well  as  the  cost  of  replacing  obsolete  parts 
or  even  redesigning/modifying  the  equipment  to  make 
it  compatible  with  the  new  technology  parts. 

Additionally,  one  of  the  prevailing  and  flawed  opinions 
in  applying  COTS  technology  to  DOD  weapon  systems 
is  that  “if  the  technology  exists  in  the  commercial 
marketplace,  it  already  must  be  appropriate  for  use  in 
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the  military  and,  therefore,  validation  and  testing  of  the 
technology  are  unnecessary  requirements.”  This  is  an 
unacceptable  risk  because  every  piece  of  equipment 
must  meet  an  acceptable  set  of  requirements  relative  to 
the  DOD  operational  environment  for  which  it  is 
intended.  The  military  mission  and  operating 
environment  can  be  distinctly  different  than  those  of 
industry,  and  technologies  must  be  tested  and  validated 
to  withstand  factors  such  as  extreme  shock,  vibration, 
and  corrosion.  The  appropriate  level  of  testing  and 
validation  must  be  determined  based  on  the  type  of 
technology  and  how  it  will  be  fielded.  Ideally,  a  COTS 
technology  may  be  subject  to  a  reduced  level  of  DOD 
testing  based  on  established  commercial  testing  data.  If 
this  is  the  case,  the  DOD  will  realize  a  cost  savings. 

When  specifying  COTS  technology,  parts 
obsolescence,  validation,  and  testing  risks  must  be 
effectively  balanced  with  system  performance,  life- 
cycle  costs  (affordability),  and  overall  supportability. 
One  management  tool  and  methodology  that  helps 
systems  engineers  identify  COTS  technology  risk 
factors  was  developed  by  the  Naval  Air  Warfare  Center 
Aircraft  Division,  Lakehurst,  New  Jersey 
(NAVAIRWARCENACDIVLKE)  under  the  Naval  Air 
Systems  Command.  The  Risk-Based  COTS  Systems 
Engineering  Assessment  Model  is  a  tool  that  addresses 
the  need  for  better  systems  engineering  integrated 
decision-making.  The  model  can  improve  the  military 
systems  engineering  management  decision  framework 
so  that  COTS  technology  integration  is  considered  as 
an  alternative  to  “cradle-to-grave”  development  of 
DOD  weapon  systems.  Ultimately,  the  model  reduces 
risk  and  uncertainty  in  the  engineering  of  defense 
systems  that  use  COTS  technology. 

2.0  ACQUISITION  REFORM  INITIATIVE 

Several  key  measures  facilitate  the  accelerated 
introduction  of  commercial  technologies  into  DOD 
weapon  systems. 

2.1  COTS  Technology 

Various  DOD  directives  have  led  to  the  current  focus 
on  procuring  COTS  technology.  For  example,  DOD 
Directive  5000.1  prescribes  a  systems  engineering 
approach  throughout  the  entire  life  cycle  of  a  system 
and  categorizes  the  four  basic  types  of  acquisition  in 
order  of  preference; 

a.  Modification  of  existing  system 

b.  Procurement  of  a  COTS  item 

c.  Procurement  of  a  nondevelopmental  item 

d.  Development  of  a  new  system. 

The  DOD’s  Acquisition  Reform  Initiative  is  a 
mandated  effort  to  reduce  the  cost  of  systems 
acquisition  through  measures  such  as  COTS 
technology  procurement.  The  benefits  of  DOD 


acquisition  of  COTS  technology  can  be  significant, 
especially  with  respect  to  eliminating  developmental 
costs,  but  the  appropriate  risk  factors  must  be  explored 
for  each  unique  case. 

2.2  Open  System  Architecture 

A  major  contributor  to  the  success  of  COTS-based 
technology  solutions  is  an  open  architecture  design. 
DOD  Directive  5000.2-R  strongly  encourages  the 
design  of  open  architecture  for  DOD-developed 
systems  in  order  to  ensure  flexibility  and  scalability 
and  to  facilitate  the  insertion  and  integration  of 
technology.  In  many  cases,  industry  also  has  embraced 
open  architecture  in  order  to  promote  supportability, 
interoperability,  and  scalability  as  means  of  reducing 
production  costs  and  gaining  a  competitive  advantage. 
Manufacturers  who  employ  the  principles  of  open 
architecture  represent  reduced  risk  to  the  DOD  when 
procuring  COTS  technology. 

Some  industry  standards  promote  open  architecture. 
For  example,  small  components  such  as  valves  often 
are  designed  using  open  architecture  standards  to 
ensure  that  they  can  be  applied  to  and  interchanged 
with  a  wide  range  of  systems.  Unfortunately,  other 
types  of  mechanical  components,  such  as  pumps,  may 
not  be  adapted  as  easily  between  systems.  For  example, 
if  a  manufacturer  develops  a  system  that  includes  a 
unique  component  A,  which  for  some  reason  becomes 
unavailable  as  a  replacement  part,  then  a  new 
component  B,  possibly  from  a  different  manufacturer, 
must  be  integrated.  If  the  system  was  not  designed  with 
open  standards  to  accommodate  a  different  component, 
it  will  require  redesign  work  and/or  a  new  interface  for 
component  B  to  be  retrofitted  into  the  system. 

The  interchangeability  of  critical  parts  is  therefore  an 
important  factor  when  determining  the  risk  of  parts 
obsolescence  and  the  supportability  of  a  COTS  system. 
The  COTS  systems,  which  are  designed  with  open 
architecture  and  open  standards,  yield  reduced  risk  and 
life-cycle  costs. 

3.0  SYSTEMS  ENGINEERING 

The  impetus  for  greater  application  of  COTS 
technology  creates  a  new  systems  engineering 
challenge — to  cost-effectively  assess  and  integrate 
commercial  technologies  prone  to  continuous  change. 
Predicting  these  changes  and  ensuring  minimal  risk  can 
be  a  difficult  task.  The  overall  goal  is  to  meet  mission 
requirements  while  ensuring  cost,  schedule,  and 
performance  throughout  the  weapon  system  life  cycle. 
This  goal  can  be  compromised  by  poorly  estimating  the 
risks  involved  with  COTS  technology  insertion. 

To  compensate  for  rapid  COTS  technology  changes, 
systems  engineers  must  identify  strategies  and  a 
common  framework  that  will  aid  in  projecting  and 
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mitigating  these  issues  early  in  the  weapon  system 
development  cycle.  By  addressing  market  (i.e., 
technology  manufacturer)  concerns  early,  the  volatility 
of  COTS  technology  insertion  can  be  controlled  and 
potential  problems,  such  as  parts  obsolescence,  can  be 
minimized. 

The  first  step  toward  meeting  this  objective  is  to  assess 
the  viability  of  the  commercial  technology  in  the 
context  of  performance,  complexity,  criticality, 
supportability,  and  life-cycle  cost  factors.  The  Risk- 
Based  COTS  Systems  Engineering  Assessment  Model 
is  a  common  framework  that  allows  systems  engineers 
to  meet  the  goals  and  minimize  the  risks  of  COTS 
technology  insertion  at  any  phase  during  the  weapon 
system’s  acquisition  life  cycle.  The  model  can  be  used 
as  a  life-cycle  risk  assessment  methodology  to 
determine  lifelong  buys  versus  COTS  technology 
insertion,  to  identify  open  architecture  and  open 
standards,  to  assess  supportability,  to  design  processes, 
and  to  select  materials.  It  is  a  life-cycle  management 
tool  for  dealing  with  the  risk  of  obsolescence  and 
overcoming  the  barriers  to  using  COTS  technology  in 
defense  systems.  An  innovative  aspect  of  the  model  is 
the  use  of  a  cube  diagram  to  represent  the  relative  risks 
of  different  COTS  alternatives  (reference  Section  4.3). 

4.0  ASSESSMENT  AND  VALIDATION 
MODEL 

The  Risk-Based  COTS  Systems  Engineering 
Assessment  Model  was  developed  to  ensure  that 
systems  engineers  can  select  the  most  cost-effective 
COTS  equipment  based  on  its  affordability,  reliability, 
mission  requirements,  and  ability  to  accommodate 
replacement  and/or  future  modification.  A  risk-based 
approach  to  decision-making,  the  model  enables 
systems  engineers  to  apply  a  variety  of  risk 
perspectives  while  using  information  from  technology 
market  analyses.  Eor  example,  market  analysis 
information  can  be  used  to  assess  whether  a 
manufacturer  uses  open  architecture  or  is  likely  to  have 
the  “staying  power”  to  provide  long-term  support.  The 
model  also  assists  with  determining  the  level  of 
validation  and  testing  required  to  further  reduce  the 
risk  of  using  COTS  equipment.  The  model  allows 
competing  COTS  equipment  to  be  judged  fairly  in 
order  to  identify  which  manufacturer  allows  the  DOD 
to  take  the  greatest  advantage  of  using  COTS 
equipment  (e.g.,  the  manufacturer  whose  technology 
meets  the  mission  requirements,  uses  open  architecture, 
and  provides  verifiable  data  to  limit  the  amount  of 
DOD  testing  and  validation  required). 

Eor  instance,  the  model  can  assist  in  recognizing  the 
worst-case  parts  obsolescence  scenario — selecting 
equipment  that  has  a  high  perceived  risk  of  not 
functioning  during  a  conflict  as  a  result  of  the 
unavailability  of  parts  or  the  incompatibility  of  newly 
upgraded  parts  with  fielded  equipment.  The  best-case 


scenario  is  one  in  which  the  equipment  meets  the 
mission  by  using  readily  available  and  supportable 
COTS  parts  and  open  architecture.  In  this  case, 
components  can  be  replaced  to  compensate  for,  as  well 
as  to  take  advantage  of,  advances  in  technology. 

The  model  is  intended  to  be  a  tool  that  can  be  applied 
throughout  the  lifetime  of  a  system.  Ideally,  the  model 
should  be  used  to  perform  a  baseline  analysis  when 
system  development  commences.  The  analysis  can  be 
revised  and  adjusted  later  during  each  major  milestone 
or  acquisition  phase  to  account  for  new  requirements  or 
factors  that  were  not  originally  relevant  or  defined.  If  a 
weapon  system  has  progressed  beyond  the 
development  stage,  the  model  can  still  be  applied  at 
any  time  to  assist  with  COTS  technology  decision¬ 
making.  The  model  functions  best  when  it  is  combined 
with  a  suitable  life-cycle  cost  model. 

Overall,  the  model  works  iteratively  to  define 
requirements,  insert  market  knowledge,  and  identify 
risk.  Each  COTS  alternative  is  applied  to  the  model.  If 
alternative  1  yields  unacceptable  risk,  consecutive 
alternatives  are  evaluated  until  the  alternative(s)  with 
the  least  risk  is  identified.  If  all  of  the  available 
alternatives  have  unacceptable  risk,  either  the  mission 
requirements  must  be  reevaluated  or  other  suitable 
alternatives  must  be  found  through  additional  market 
analysis.  The  model  defines  risk  as  a  function  of 
mission  criticality,  technical  complexity,  and  life-cycle 
costs.  Eor  example,  the  risk  of  parts  obsolescence  is 
translated  as  a  risk  to  the  mission  and  as  a  potential 
impact  on  life-cycle  costs.  Eurthermore,  unless  the  item 
has  been  designed  using  open  architecture,  the  risk  of 
parts  obsolescence  is  evaluated  according  to  the 
technical  complexity  of  the  COTS  technology — the 
more  technically  complex  the  technology,  the  greater 
the  perceived  risk  of  parts  obsolescence. 

The  goal  of  engineering  suitable  COTS  equipment 
solutions  can  be  reached  by  employing  the  model  in 
accordance  with  the  following  steps: 

a.  Perform  market  surveillance  and  construct  an 
ongoing  commodity  strategy  for  future  needs. 

b.  Logical  Solution — Perform  an  operational 

requirements  analysis  (e.g.,  define  mission, 
performance,  functionality,  reliability, 

maintainability,  supportability,  and  environmental 
requirements). 

c.  Physical  Solution — Translate  requirements  into 
COTS  solutions  by  applying  market  analysis. 

d.  Alternatives  Risk  Assessment  (a  central  element 
of  the  model) — Perform  an  alternatives  and  risk 
assessment 
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>  Evaluate  the  ability  of  each  alternative  to  meet 
the  defined  requirements. 

>  Determine  the  requirements  thresholds. 

>  Determine  the  requirements  validation  and 
testing  required. 

>  Determine  supportability  plans  and  evaluate 
open  architecture  design. 

>  Determine  risk  factors  to  performance,  cost, 
and  schedule. 

>  Determine  the  estimated  life-cycle  cost. 


e.  Mitigation  of  Risk — Perform  verification  and 

qualification 

>  Analyze  commercial  data  and  past 
performance 

>  Determine  required  testing  and  validation 
of  sample  equipment. 

Figure  1  summarizes  these  steps  and  shows  how  the 
model  fits  into  the  traditional  systems  requirements 
decision-making  process. 


Figure  1.  Summary 


Figure  2  represents  the  iterative  process  that  occurs 
after  the  need  for  a  piece  of  equipment  is  defined. 
Blocks  1,  2,  and  3  relate  to  defining  requirements, 
determining  market-based  COTS  solutions,  and 
assessing  each  COTS  alternative.  If  none  of  the  COTS 
alternatives  represents  acceptable  risk,  the  mission 
requirements  must  be  reevaluated  or  a  decision  must  be 


made  to  develop  the  equipment  in-house  (DOD  design 
and  develop)  rather  than  procuring  COTS  equipment. 
If  one  or  more  COTS  alternatives  represent  acceptable 
risk,  a  procurement  strategy  for  COTS  equipment 
should  be  formulated  based  on  the  best  alternative. 
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Mission  Need 


•  user  input 

•  thresholds  and  objectives 

•  mission  profile 

•  Ao,  MTBF,  MTTR 

•  function,  performance,  environment 

•  support 


•  market  research  (surveillance  &  investigation) 

•  data  analysis  (performance,  RAMS,  supportability) 

•  survey  of  suppliers  and  references  (past  performance) 

•  market  report 

•  identification  of  COTS  alternatives 


Physical  Solution 


no 


•  evaluation  of  COTS  alternatives 

•  requirements  tradeoff  analysis 

•  LCC-CAIV  analysis 

•  risk  assessment  (performance,  cost,  schedule) 

•  determine  procurement  strategy 

•  open  architecture  (parts  obsolescence  risk) 

•  validation  (  performance,  reliability,  supportability) 

•  assess  criticality  and  complexity 


Reassess  the  Mission  Need 
or  Develop  DOD  Design 
(i.e..  Do  Not  Procure  COTS) 


Alternative  Risk 
Assessment 
(Central  Element 
of  Model) 


J 


Figure  2.  Iterative  Decision  Analysis  Process 


4.1  The  Logical  Solution 

Block  1  of  Figure  2,  Perform  Operational 

Requirements  Analysis,  includes  the  following 

substeps: 

•  Compile  user  input  (e.g.,  feedback  from 
shipboard/flight  line  personnel). 

•  Define  the  mission  profile  and  mission  analysis. 

•  Define  thresholds  and  objectives. 

•  Perform  a  functional  analysis. 

•  Perform  a  supportability  analysis. 

•  Define  performance  attributes. 

•  Determine  operational  availability  (Ao),  allowable 
mean  time  between  failures  (MTBF),  and  mean 
time  to  repair  (MTTR). 

•  Define  the  operational  environment  requirements 
(e.g.,  shock,  vibration,  weather). 

•  Determine  estimated  inventory  and  allocation 
allowances. 

4.2  The  Physical  Solution 

Block  2  of  Figure  2,  entitled  Translate  Requirements 

into  COTS  Solutions,  includes  substeps  such  as 


performing  market  research,  analyzing  market  data, 
and  surveying  COTS  equipment  suppliers.  Market 
research  builds  on  continuous  market  surveillance  to 
develop  a  commodity  strategy  and  market 
investigation.  The  market  investigation  should  yield 
COTS  alternatives  that  meet  the  requirements  of  the 
logical  solution  (defined  above).  A  typical  market 
investigation  results  in  an  evaluation  and  report  of  the 
following  items: 

•  Summary  of  market  surveillance  information 

•  List  of  potential  sources 

•  Survey  of  potential  supply  sources  (e.g.,  Internet 
search,  journals,  Commerce  Business  Daily 
contract  awards,  etc.) 

•  Input  from  references  (i.e.,  current  users  of  similar 
equipment) 

•  Compilation  of  equipment  capabilities  (e.g., 
performance,  supportability,  history,  etc.). 

Table  1  lists  some  factors  that  should  be  considered 
when  reviewing  open  standards,  equipment  profiles, 
and  their  related  technologies  and  products. 
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Table  1.  Market  and  Technology  Supplier  Analysis 

(Source:  Next  Generation  Computer  Resources  (NGCR),  Document  No.  AST002,  Version  0.04  of  the  NGCR 
Supportability  Guide,  draft  dated  27  April  1995,  SPAWAR.) 


Maturity  of  the  Standards, 
Technologies,  and  Products 

>  Is  the  technology  mature? 

>  Are  the  products  fairly  stable? 

>  What  is  the  product  “upgrade”  cycle  time? 

>  When  is  the  next  planned  update? 

>  Are  the  products  being  refined  or  significantly  changed  during  each  cycle? 

Multiple  Product  Sources 

>  Are  there  multiple  sources  for  products  that  meet  the  requirements  analysis? 

>  Are  these  products  interoperable? 

>  Do  these  products  merely  accept  data  from  each  other  or  do  they  meet  the  same 
performance  levels  (interchangeability)? 

Market  Acceptance 

>  Is  the  standard,  profile,  or  product  well  accepted  in  the  commercial  marketplace? 

>  What  are  the  respective  vendors’  market  shares? 

>  Are  the  commercial  markets  large  enough  to  imply  that  long-term  support  and 
upgrade  of  the  product  will  be  an  investment  borne  by  the  commercial  market 
sector  or  will  the  DOD  become  the  only  user  in  a  relatively  short  time? 

Product  Line  Families 

>  Do  product  families  exist? 

>  Will  usage  of  a  given  product  tie  the  DOD  to  a  product  family? 

>  Will  such  a  relationship  be  expensive? 

>  Is  the  existing  support  structure  well-suited  to  the  operational  requirements? 

>  Will  supplements,  upgrades,  or  replacements  be  necessary  (e.g.,  technical  data, 
training,  repair,  spare  parts  support,  etc.)? 

>  Should  the  product  family  or  the  individual  product  alone  be  approved  for  use? 

Test  and  Evaluation 

>  What  ongoing  test  and  evaluation  parameters  are  employed  by  the  vendor? 

>  How  would  the  DOD  test  this  product? 

>  Will  the  existing  test  capability  and  data  meet  the  DOD’s  needs? 

>  Will  test  data  from  families  of  products  be  applicable? 

>  How  much  will  required  testing  cost? 

Technical  Data 

>  Are  the  technical  data  provided  by  the  various  vendors  sufficient? 

>  Are  the  data  useable?  If  no,  what  problems  can  be  foreseen? 

>  What  workarounds  are  necessary? 

>  What  additional  data  are  necessary? 

Configuration  Management 
(CM) 

>  Is  the  contractor’ s  CM  program  adequate  to  meet  weapon  system  program  office 
needs? 

>  Can  the  contractor’s  CM  program  be  modified  or  supplemented  if  necessary? 

By  the  contractor  or  the  government? 

>  What  will  the  cost  be  and  who  will  bear  this  cost? 

Availability 

>  What  is  the  operational  availability  (Ao)? 

>  What  is  the  inherent  availability? 

>  What  is  the  mean  time  to  repair  (MTTR)? 

>  What  is  the  mean  time  between  failures  (MTBF)? 

Performance  Monitoring 
and  Built-in  Test 

>  Does  the  product  have  a  built-in  self-test? 

>  Is  the  self-test  capability  sufficient  from  a  systems-level  viewpoint? 

>  Will  the  self-test  be  difficult  to  reintegrate  when  updates  occur  (e.g., 
engineering,  training,  configuration  status  and  management,  supply  support)? 

Quality  Assurance 

>  Does  the  vendor  provide  a  warranty  and  what  is  included  in  the  warranty? 

>  Is  the  vendor  ISO  9000  compliant? 

>  What  other  quality  assurance  measures  does  the  vendor  provide? 
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4.3  The  Alternatives  Risk  Assessment 

Block  3  of  Figui'e  2,  entitled  Perform  COTS 
Assessment,  includes  the  following  substeps; 

•  Classify  each  COTS  alternative  based  on  criticality 
and  complexity.  (Since  each  alternative  is  a 
possible  solution  for  the  same  need,  it  is  expected 
that  the  criticality  will  remain  the  same  for  each 
alternative;  however,  the  complexity  may  vary 
with  each  alternative.). 

•  Evaluate  the  anticipated  life-cycle  cost  analysis  for 
each  COTS  alternative. 

•  Assess  each  COTS  alternative  based  on: 

>  Ability  to  meet  threshold  and  objective 
requirements 

>  Supportability  (e.g.,  open  architecture  design 
reduces  parts  obsolescence) 

>  Life-cycle  cost. 

•  Assess  the  risk  of  each  COTS  alternative; 

>  Technical  risk  =  /  (mission  criticality, 
technical  complexity,  life-cycle  cost  [LCC]) 

To  perform  the  alternatives  risk  assessment — the 
central  element  of  the  model — the  technical  complexity 
and  criticality  of  each  COTS  alternative  must  be 
established.  The  alternatives  are  categorized  using  the 
following  definitions; 


•  Complexity 

>  Non-Complex  -  A  nonrepairable  piece  of 
equipment  (i.e.,  consumable)  or  a  repairable 
piece  of  equipment  with  no  repairable 
subassemblies. 

>  Complex  I  -  Equipment  with  one  or  more 
repairable  subassembly. 

^  Complex  II  -  Equipment  that  meets  the 
definition  of  Complex  I  and  is  self-powered 
(i.e.,  engine,  hydraulic,  electric,  or  pneumatic- 
powered). 

^  Complex  III  -  Equipment  that  meets  the 
definition  of  Complex  II  and  has  feedback 
control  (i.e.,  does  not  have  data  acquisition). 

•  Criticality 

>  Non-Critical  -  Requires  scheduled  and/or 
unscheduled  maintenance,  but  is  not 
considered  mission-  or  safety-critical. 

>  Mission  Critical  -  Eailure  of  this  equipment 
could  damage  the  weapon  system  or  degrade 
the  weapon  system  mission. 

^  Safety  Critical  -  Eailure  of  this  equipment 
could  harm  personnel. 

Next,  the  equipment  alternatives  should  be  assessed  to 
determine  approximate  life-cycle  costs.  At  this  point, 
the  alternatives  can  be  positioned  on  a  three- 
dimensional  cube  that  forms  the  basis  of  the  Risk- 
Based  COTS  Systems  Engineering  Assessment  Model 
(refer  to  Eigure  3). 


MODERATE  RISK  -  MODERATE  VALIDATION 
LOW  RISK  -  LOW  VALIDATION 

MARKET  QUALITY  /  REQUIREMENT 
PROBLEM 


Figure  3.  Degree  of  Validation  as  a  Function  of  Technical  Risk 

Risk  =  /  (mission  criticality,  technical  complexity,  LCC) 


This  cube  allows  the  systems  engineer  to  determine  the 
degree  of  validation  required  as  a  function  of  technical 
risk.  Risk  is  a  function  of  three  factors:  criticality, 
complexity,  and  life-cycle  cost.  The  cube  enables 


systems  engineers  to  visualize  alternatives  as  a 
composite  of  their  contribution  to  the  mission  versus 
their  ease  of  repair  and  supportability  versus  cost.  The 
y-axis  of  the  cube  represents  increasing  complexity. 
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and  the  x-axis  represents  increasing  criticality.  The  z- 
axis  represents  increasing  life-cycle  costs.  Each 
available  COTS  alternative  should  be  positioned  in  a 
sector  of  the  cube.  The  cube  is  color-coded  to  indicate 
which  sectors  represent  low,  moderate  and  high  risk, 
which  correspond  to  low,  moderate,  and  high 
requirements  for  equipment  validation.  For  example, 
the  color-coded  location  of  the  sector  for  those 
alternatives  that  are  noncritical  and  noncomplex  with  a 
low  life-cycle  cost  indicates  low  risk  and,  therefore, 
relatively  low  requirements  for  equipment  validation. 
The  color-coded  location  of  the  sector  for  those 
alternatives  that  are  highly  mission-  or  safety-critical 
and  highly  complex  with  a  high  life-cycle  cost 
indicates  high  risk  and  relatively  high  validation 


requirements.  The  model  also  indicates  potential 
acquisition  problems,  such  as  alternatives  that  fall  into 
the  sector  for  low  complexity  and  low  criticality  with 
high  life-cycle  costs.  Such  sectors  are  color-coded  to 
indicate  either  a  problem  with  the  availability  of  an 
appropriate  alternative  in  the  marketplace  or  that  the 
requirements  have  been  poorly  defined. 

Figure  4  illustrates  a  fragmented  version  of  the  cube 
that  enables  better  visualization  of  each  sector.  This 
model  expands  the  cube  to  include  sectors  based  on  all 
four  definitions  of  complexity. 


COMPLEX  III 


COMPLEX  II 


COMPLEX  1 

K — 

7 

_ 

/ _ L. 

/ 

NON-COMPLEX 


X _ / 

/ 

r 

_ / 

L( 

REQUIREMENTS 

VECTOR 


HIGHER  RISK  -  HIGH  VALIDATION 

I  I  MODERATE  RISK  -  MODERATE  VALIDATION 

I  I  LOW  RISK  .  LOW  VALIDATION 

I  I  MARKET  QUALITY /REOUIREMENT 

PROBLEM 

HIGH  LCC 


NON  MISSION/ 

CRITICAL  SAFETY 

CRITICAL 


Figure  4.  Degree  of  Validation  as  a  Function  of  Technical  Risk  -  Fragmented  Cube 

Risk  =  /  (mission  criticality,  technical  complexity,  FCC) 


As  an  example  of  the  different  components  and  support 
equipment  that  comprise  a  weapon  system.  Figure  5  is 
a  version  of  the  fragmented  cube  with  various  pieces  of 
aircraft  support  equipment  labeled  on  the  appropriate 
sectors.  By  using  the  fragmented  cube  to  visualize  an 


entire  weapon  system,  systems  engineers  can  select  the 
areas  that  may  be  most  appropriate  for  COTS 
equipment  to  be  inserted  and/or  ensure  that  the 
appropriate  level  of  validation  occurs  when  evaluating 
COTS  equipment  based  on  risk. 
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EQUIPMENT 

SAMPLES 


Acronym  List 

COMPLEX  III 

SETS-standard  engine  test  system 

HCTS-hydraulic  component  test  stand 

JASU-jet  air  start  unit  complex  n 

ADTS-air  data  test  set 

MEPP-mobile  electric  power  plant 

AGTS-aircraft  generator  test  stand  complex  i 

NDI-nondestructive  inspection  equipment 

O2  GEN-oxygen  generating  cart 

MAINT  PLAT-maintenance  platform  non-compl 


NON  MISSION/ 

CRITICAL  SAFETY 

CRITICAL 

- ►  Higher Ao  Required 


Figure  5.  Weapon  System  Example  of  Fragmented  Cube 

Risk  =  /  (mission  criticality,  technical  complexity,  LCC 


4.4  The  Mitigation  of  Risk 

When  assessing  COTS  alternatives,  it  is  necessary  to 
determine  what,  if  any,  performance  and  environmental 
degree  of  reliability  and  maintainability  (R&M) 


validation  and  testing  are  required.  Figure  6  shows  an 
example  of  a  logical  flow  diagram  validation  strategy 
for  COTS  equipment  R&M  validation  decision  factors 
based  on  criticality  and  complexity.  The  goal  is  not  to 
“overtest”  or  “undertest”  COTS  equipment. 


Figure  6.  Reliability  and  Maintainability  Validation  Strategies 

(Source:  Janet  L.  French,  NAVAIR  Reliability  Engineering) 


Tables  2  and  3  represent  the  types  of  commercial 
equivalent  data  and  equivalent  testing  that  can  be  used 
to  assess  the  degree  of  additional  testing  or  validation 
that  may  be  required.  In  each  case,  a  lack  of 
commercial  data  or  testing  protocols  increases  risk 


and  may  necessitate  full  or  partial  DOD  testing  of  the 
equipment.  The  goal  is  to  take  advantage  of  existing 
data  and  testing  to  reduce  the  cost  of  required  R&M 
testing  and  validation. 


7-10 


Table  2.  R&M  Validation 
Analysis  and  Data 


Analysis  Data 
Required 

Critical  & 
Noncomplex 

Complex 
&  Not 
Critical 

Electrical/ 
Electronic 
Critical  & 
Complex 

Mechanical 
Critical  & 
Complex 

Critical  & 
Complex  II 

Critical  & 
Complex  III 

R  design  practices 

/ 

/ 

/ 

R  prediction 

/ 

/ 

/ 

EMECA 

/ 

/ 

/ 

/ 

M  design  practices* 

/ 

/ 

/ 

M  prediction* 

/ 

/ 

/ 

*Maintenance  philosophy-dependent 


Table  3.  R&M  Validation 
Testing 


Testing 

Critical  & 
Noncomplex 

Complex  & 
Not  Critical 

Electrical/ 
Electronic 
Critical  & 
Complex 

Mechanical 
Critical  & 
Complex 

Critical  & 
Complex  II 

Critical  & 
Complex  III 

ESS 

/ 

/ 

/ 

RQT 

/ 

/ 

/ 

/ 

RD/GT* 

As  required* 

As  required* 

M  demo** 

/ 

/ 

/ 

/ 

*For  systems  where  several  COTS  items  are  integrated. 
**Maintenance  philosophy  dependent 

Legend; 

R — reliability 

FMECA — failure  modes  effects  and  criticality  analysis 

M — maintainability 

ESS — environmental  stress  screening 

RQT — reliability  qualification  testing 

RD/GT — reliability  development/growth  testing 

When  conducting  an  R&M  risk  assessment,  the 
following  pertinent  questions  should  be  included: 

•  Has  the  vendor  provided  sufficient  information  to 
indicate  that  R&M  requirements  can  be  achieved? 

•  Are  there  any  new  or  untried  technologies  or 
components  within  the  product  that  have  a  limited 
or  nonexistent  record  of  reliability  performance? 

•  What  techniques  does  the  vendor  use  to  maintain 
or  improve  product  reliability  and  quality? 

•  How  does  the  vendor  select  subvendors  (e.g., 
qualified  lists,  lowest  cost,  etc.)? 

•  Does  the  vendor  verify  component  quality? 


•  Are  there  any  frequent  failures  that  could  impact 
safety  or  the  mission? 

•  Are  there  any  frequent  failures  of  high-cost  items? 
Hard-to-replace  items?  Hard-to-maintain  items? 

•  Is  the  commercial  use  environment  sufficiently 
similar  that  the  data  are  indicative  of  the  types  of 
failures  likely  in  the  DOD  environment? 

•  Are  there  any  test  data  and  are  they  verifiable? 

Eigure  7  illustrates  the  decision  factors  related  to 
COTS  equipment  supportability  validation 
requirements.  This  analysis  shows  that  open 
architecture  is  beneficial  to  COTS  equipment 
alternatives. 
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Figure  7.  Supportability  Validation  Strategies 
Logistics  Validation 

(Source:  Edward  F.  Waraksa,  NAVAIR  Logistics  Management) 


Various  types  of  commercial  data  may  be  available  to 
perform  R&M  and  supportability  analyses  of  COTS 
alternatives.  Table  4  illustrates  several  key  sources. 


Similar  validation  flow  diagram  strategies  must  be 
developed  to  address  performance  as  well  as 
environmental  requirements. 


Table  4.  Commercial  Data  Sources  Related  to  Validation  of  R&M  and  Supportability 


Historical  R&M  Experience 

•  Estimates  of  expected  reliability 

•  Warranty  provisions 

•  Customer  satisfaction  indices 

Internal  Manufacturing  Quality 

Procedures 

•  Production  controls 

•  ISO  9000  or  similar  techniques 

•  Testing  procedures 

Vendor  or  Component  Selection  Policy 

•  Parts  control  methods 

•  Quality  control  techniques 

•  Testing  procedures 

•  Environmental  stress  screening 

Design  Approach 

•  Environmental  approach 

•  Part  derating  procedures 

•  Eault  tolerance  features 

•  Ruggedization  concepts 

•  Built-in  test  features 

•  Ease-of-maintenance  features 
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In  summary  (refer  to  Figure  1),  the  Risk-Based  COTS 
Systems  Engineering  Assessment  Model  components 
can  be  summarized  as  the  following  steps  -  beginning 
with  the  mission  need,  requirements  definition  and 
analysis,  market  research  and  identification  of  COTS 
solutions,  use  of  the  fragmented  cube  and  validation 
flow  charts  to  assess  and  reduce  risk  and,  finally, 
providing  input  for  procurement. 

5.0  CONCLUSIONS 

In  summary,  the  DOD’s  increasing  reliance  on 
advanced  technology,  such  as  electronics,  dramatically 
increases  the  cost  of  developing  weapon  systems,  as 
well  as  the  operational  cost  of  redesigning  and 
upgrading  these  systems  as  technologies  change.  To 
avoid  some  of  these  costs,  the  DOD  must  take 
advantage  of  industry’s  ability  to  bring  components 
and  systems  to  market  faster  than  the  DOD  can  develop 
them.  It  is  important  to  weigh  the  risks  of  COTS 
technology  over  the  life  cycle  of  the  system  and  insert 
these  commercial  technologies  where  the  risks  and 
benefits  are  prudent.  Without  proper  management, 
COTS  can  be  a  drawback  as  a  result  of  poorly  defined 
risk — such  as  the  likelihood  of  performance  and  cost 
risks  as  well  as  parts  obsolescence  in  the  field.  The 
Risk-Based  COTS  Systems  Engineering  Assessment 
Model  serves  to  define  such  risks  and  helps  systems 
engineers  make  informed  decisions. 

The  Risk-Based  COTS  Systems  Engineering 
Assessment  Model  provides  a  common  framework  for 
making  COTS  technology  decisions  by  assessing  the 
relative  risk  of  each  COTS  alternative.  It  also  provides 
assistance  in  determining  the  appropriate  degree  of 
validation  required  to  verify  that  a  COTS  alternative 
can  be  transferred  to  the  military  environment. 

To  take  advantage  of  COTS  technology  and  better 
apply  the  model,  the  systems  engineering  community 
needs  the  following: 

•  Better  requirements  analysis  tools  that  incorporate 
risk. 

•  Better  industry  information  (i.e.,  life-cycle  cost 
data,  time  until  market  release/update  data,  and 
supportability  data. 

•  Better  market  surveillance  and  segmentation  (i.e., 
systems  engineers  must  become  cognizant  of 
market  factors  and  sectors  for  different 
technologies). 

•  Better  system  of  open  architecture  standards  in  the 
marketplace  (e.g.,  electronic  and  mechanical 
standards  that  incorporate  open  architecture). 

•  Better  assessment  tools  that  are  standardized  and 
used  by  all  NATO  military  organizations. 

The  Risk-Based  COTS  Systems  Engineering 
Assessment  Model  offers  important  benefits  and 


insight  to  the  overall  weapon  system  acquisition 
management  process.  It  should  be  noted  that 
significant  work  must  still  be  invested  to  make  the 
application  more  efficient,  such  as  refining  the 
functional  interrelationship  between  complexity, 
mission,  and  cost.  The  need  to  further  optimize  the 
model  is  necessary  if  better  fidelity  is  desired. 
Integrating  and  automating  the  complexity  criteria  with 
mission  criticality  and  cost  analysis  is  the  ideal  formula 
for  concurrent  engineering  analysis,  which  when 
applied  improves  the  chances  of  selecting  effective 
commercial  equipment.  Automating  and  combining 
the  model  can  significantly  improve  implementation 
and  accelerate  the  transfer  of  commercial  technology  in 
a  synergistic  manner. 

The  authors  would  like  to  acknowledge  Janet  L.  French 
and  Edward  F.  Waraksa  for  their  contributions  to  this 
paper. 
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Summary 

The  military  sector  is  characterised  by  specific  aspects 
such  as  small  series,  high  reliability,  long  life-cycle 
products.  In  this  context,  the  DGA  wished  to  set  up 
means  to  develop  specific  integrated  circuits  for  the 
durability  of  electronic  systems. 

Thus,  in  1995,  a  first  COCISPER  contract  has  been 
awarded  to  a  Consortium  fully  representative  of  the 
industry  in  France. 

It  is  aimed  to  establish  a  methodology  guide  for 
designing  ASIC  taking  into  account  the  needs  for  system 
durability.  Therefore,  it  defines  an  industrial  standard 
following  the  withdrawal  of  mil-spec  ones. 

The  guide  produced  within  this  project  specifies  the 
general  development  plan  of  numeric  integrated  circuits 
at  the  ASIC  design  process  level,  but  also  at  the 
equipment  and  system  specification,  validation  and 
qualification  stages.  It  proposes  recommendations 
applicable  to  the  whole  industry. 

A  follow-up  study  has  been  awarded  to  the  same 
Consortium  in  1998  which  aims  at  experimenting  and 
validating  the  COCISPER  guide  on  real  applications,  but 
also  at  updating  it  to  take  into  account  the  Programmable 
Logic  Devices  (PLD)  ant  recent  techniques  such  as  the 
use  of  Virtual  Components. 

In  addition,  an  evolution  of  the  guide  facilitating  the 
access  to  information  has  been  asked.  A  HMTL  version 
is  now  developed  and  available. 

Introduction 

Progress  in  microelectronic  technology  has  allowed  the 
use  of  increasingly  high-performance  Application 
Specific  Integrated  Circuits  (ASIC)  for  the  benefit  of 
systems.  However,  their  use  involves  problems 
associated  with  the  particularities  of  those  integrated 
circuits  and  also  from  the  characteristics  of  military  and 
aerospace  equipment  and  systems:  Complexity, 
performance,  reliability,  cost,  harsh  environments, 
limited  production  lead  times  and  long  term  availability 
for  the  durability  of  systems. 


COCISPER,  which  stands  for  “Conception  Circuits 
Integres  Specifiques  et  Perennite».  is  firstly  the  name  of 
a  project  seeking  to  draw  up  a  methodological  guide  to 
ASIC  and  PLD  designs  with  a  view  to  ensuring  system 
durability  and  control  of  the  long  term  availability 
attributes  surrounding  development  process.  These  are 
the  fundamental  objectives  of  the  guide. 

COCISPER  is  thus  also  the  name  of  the  industrial 
Consortium  which  is  entrusted  in  the  realisation  of  that 
project,  with  the  support  of  French  DGA.  The 
Consortium  comprises  representatives  of  seven  defence 
and  aerospace  sector  companies,  leaded  by  Matra  BAe 
Dynamics,  and  the  partnership  of  Aerospatiale  Matra 
Missiles,  Astrium,  Sagem.SA,  Thomson-CSF  Detexis, 
Thomson-CSF  Sextant,  Thomson-CSF  TTM. 

Project  objective  is  to  pool  experience  and  methods  over 
a  sufficiently  broad  industrial  base  to  produce  the 
operational  recommendations,  outline  procedures  and 
generic  procedures  forming  the  guide.  They  are  based  on 
the  best  methodological  practice  (state-of-the-art)  to 
emerge  from  the  sharing  of  experience  and  joint 
formulation  of  the  new  recommendations. 

The  guide  is  drawn  up  by  industry,  for  industry.  It  is  an 
operational  guide:  It  is  neither  an  imposed  framework 
nor  an  additional  constraint.  On  the  contrary,  it  should 
enable  everyone  to  develop  their  own  procedures 
consistent  with  in-house  development  references. 
Depending  on  the  nature  of  the  requirements,  the  guide 
may  concern  system  manufacturers,  equipment 
manufacturers,  in-house  ASIC  functions  or  design 
centres  providing  services,  supply  and  production 
functions  and  contractors  in  development  (CAD  and 
software  tool  suppliers,  founders). 

COCISPER  also  wants  to  take  advantage  of  the  new 
quality  assurance  approaches  developed  in  the 
electronics  industry  and  thereby  to  promote,  through  the 
methodological  guide,  changes  in  practice.  For  example: 

•  Specify  requirements  first,  not  solutions; 

•  Define  and  characterise  processes; 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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•  Do  not  wait  for  the  final  result  before  measuring 
how  appropriate  they  are; 

•  Validate  and  react:  do  not  consider  the  prototype  to 
be  the  end  of  the  project’s  life  cycle. . . 

Objectives  of  the  guide 

However,  their  use  involves  problems  associated  with 
the  particularities  of  those  integrated  circuits: 
performance,  cost,  low  production  volume,  lead  times, 
etc.  These  constraints  arise  also  from  the  characteristics 
of  military  and  aerospace  equipment  and  systems: 
complexity,  performance,  reliability,  harsh  environments, 
limited  production  and  durability. 

As  previously  said,  durability  is,  at  this  time,  one  of  the 
main  issue  for  military  and  aerospace  equipment  and 
systems.  Contemplating  system  durability  at  ASIC  level 
will  mean  either  ensuring  durability  of  the  integrated 
circuit  or  maintaining  the  ASIC  function  at  card  level 
throughout  the  life  cycle  of  the  system. 

In  this  context,  COCISPER’s  objective  is  to  draw  up  a 
generic  development  plan  applicable  to  digital  ASIC.  It 
takes  account  of  durability  requirements  at  system  level, 
development  quality,  and  control  of  economic 
conditions.  The  flexibility  essential  to  industrial 
competitivity  is  taken  into  account  in  those  objectives. 

Given  that  such  a  guide  must  command  broad  acceptance 
and  be  validated  in  real  situations,  the  approach  to 
drafting  the  COCISPER  recommendations  is  based  on 
the  following  objectives: 

•  to  create  conditions  for  acceptance  of  the  guide 
outside  COCISPER  by  targeting  all  potential  users 
of  the  methodology,  including  civil  industry; 

•  to  validate  application  of  the  recommendations  in 
practical  experiments  with  ASIC  development; 

•  to  involve  microelectronics  educational  and  training 
institutes  in  order  to  evaluate  how  COCISPER’s 
work  can  be  used  to  assist  training  in  the 
methodology  of  ASIC  design. 

This  determination  to  interact  with  the  players  in  the 
ASIC  community  must  make  this  guide  a  living  tool, 
capable  of  adaptation  to  the  markets  targeted  and  to 
developments  in  technology  or  the  state-of-the-art.  The 
work  remains  compatible  with  existing  standards  (e.g. 
ISO  9000)  and  does  not,  in  any  way,  represent  an 
additional  constraint. 

Scope  of  the  guide 

It  is  illustrated  in  figure  1.  The  COCISPER 
methodological  guide  sets  out  to  answer  a  number  of 
methodological  questions  facing  the  ASIC  designer  and 
user  community  both  from  the  technical  point  of  view 
and  from  the  practical  and  economic  points  of  view. 


INDUSTRIAL  USE  OF  THE  ASIC 


Figure  1  :  Scope  of  the  guide 


Erom  the  technical  standpoint,  this  methodological  guide 
deals  with  all  the  points  necessary  to  produce  an  ASIC, 
from  the  request  made  by  the  user  to  industrial  use  of  the 
ASIC.  It  is  constructed  around  the  ASIC  development 
cycle. 

It  takes  account  of  all  the  problems  associated  with 
industrial  control  of  that  development  cycle  and  the 
associated  methodological  support,  laying  particular 
emphasis  on  peculiarities  specific  to  the  ASIC.  It 
identifies  as  clearly  as  possible  the  parameters  that  tend 
to  degrade  service  and  ultimate  quality,  giving 
recommendations  regarding: 

•  the  control  of  contractors, 

•  the  process, 

•  the  manufacturer, 

•  the  tools, 

•  the  documentation, 

•  and  the  costs. 


In  the  context  of  the  methodological  support,  it  sets  out 
all  the  aspects  necessary  to  the  smooth  running  of  the 
whole  project,  such  as  quality  assurance,  durability 
assurance  and  of  course  project  and  risk  management,  for 
the  ASIC  is  above  all  part  of  a  project. 

Erom  the  practical  standpoint,  this  guide  is  directed  at  all 
those  who  come  into  close  or  remote  contact  with  ASIC. 
To  that  end  it  offers  a  set  of  recommendations  and 
information  about  its  use,  its  specific  vocabulary  and 
mode  of  evolution. 


The  Guide:  Content 

The  guide  concerns  a  field,  which  may  be  summarised  as 
follows: 

•  Development  flow:  Technical  Requirement 
Specification  (TRS),  choice  of  solution,  description 
of  the  functional  design  stages  through  to  the 
physical  design  stages,  specification  of  the 
interfaces  with  the  founders  and  CAD  tool 
suppliers,  validation  of  prototypes,  qualification  of 
the  ASIC  for  use,  specification  of  use,  and  supply 
specification; 

•  Support  methods  and  activities:  ASIC  activity 
management,  ASIC  project  management,  quality 
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management  and  quality  assurance,  durability 
management  and  assurance,  quality  control  and 
industrial  control,  documentation  management  and 
industrial  use  of  the  ASIC. 

Under  those  headings,  the  guide  describes  the  flow  of 
ASIC  design  -  that  is  the  operational  view  of 
development  -  and  the  methods  used  to  manage  and 
control  that  flow  -  they  are  the  process  support  activities. 

The  Technical  Requirement  Specifications 
(TRS) 

Two  essential  tasks  must  be  performed  before  launching 
the  design  of  an  ASIC; 

•  drafting  of  the  TRS 

•  a  feasibility  study  and  choice  of  solutions. 

The  TRS  is  a  reference  document  in  which  the  requester 
and  the  designer  of  an  ASIC  agree  on  the  characteristics 
of  the  product.  The  TRS  is  consistent  with  the  functional 
specification.  It  differs  from  the  latter  in  that  the 
functional  specification  expresses  the  requester’s  desires 
without  ensuring  that  they  are  realisable  under  the 
prevailing  technical  and  economic  conditions.  In  the  case 
of  the  TRS,  the  requester  makes  a  commitment  regarding 
his  requirements  and  the  associated  constraints,  and  the 
designer  a  commitment  regarding  his  ability  to  undertake 
development  of  the  circuit  with  a  guarantee  of  success. 
To  this  end,  the  TRS  must  state: 

•  the  functional  requirements  and  the  environment 
conditions; 

•  the  dependability  requirements; 

•  the  interface  requirements; 

•  the  design  and  production  requirements; 

•  the  product  qualification  and  acceptance 
requirements; 

•  the  conditions  regarding  verification  of  compliance 

with  the  requirements. 

The  TRS  is  a  contract  binding  the  customer  and  the 
supplier. 

The  feasibility  phase  (analysis  of  the  requirement, 
exploration  of  concepts,  etc)  and  definition  phase  (choice 
of  concept  and  specification  of  requirements)  must 
culminate  in  a  first  reference  version  of  the  TRS  usable 
by  the  designer.  Nevertheless,  it  would  be  a  mistake  to 
think  that  those  involved  in  these  (necessarily  short  but 
not  too  short)  preliminary  phases  can  grasp  all  the 
implications  associated  with  implementation  of  a 
function  in  a  circuit.  It  is  therefore  highly  probable  that 
this  TRS  will  evolve  during  the  design  work.  The  whole 
problem  is  therefore  to  put  in  place  solutions,  which  can 
control  the  changes  as  well  as  possible  in  order  to 
maintain  consistency  with  the  initial  definition  on  which 
the  design  centre  embarked. 


The  Design  and  Prototype  manufacture 

The  standard  flow  suggested  in  the  figure  3  includes  two 
successive  phases  entitled  design  and  manufacture 
respectively.  It  is  applicable  in  broad  outline  to  all  types 
of  ASIC,  including  programmable  ones,  subject  to  a  few 
adaptations  such  as,  for  instance,  the  elimination  of 
certain  tasks,  or  their  replacement  by  other  dedicated  to 
PLD. 

The  design  phase  divides  into  three  stages,  namely,  in 
chronological  order  of  execution: 

•  preliminary  design, 

•  structural  design, 

•  physical  design. 

Owing  to  the  strong  interactions  between  preliminary 
design  and  structural  design,  these  first  two  design  stages 
are  not  always  treated  separately  in  practice.  As  a  result, 
no  precise  formalism  at  their  common  interface  is 
defined. 

The  manufacture  phase  described  relates  solely  to 
mask-defined  ASIC.  In  the  case  of  PLD,  this  phase  is 
either  deleted  (this  is  the  case  with  circuits  programmed 
in  the  application)  or  replaced  by  programming  by  means 
of  a  dedicated  device. 

Every  phase  yields  elements  in  conformity  with  the  input 
documents,  which  have,  themselves,  been  validated.  The 
information  in  the  TRS  is  assumed  to  have  been 
validated  vis-a-vis  the  system.  Consequently,  the 
validation  operations  performed  during  design  are 
intended  solely  to  ensure  that  the  various  descriptions  of 
the  ASIC  conform  to  the  requirement  stated  in  the  TRS. 
Similarly,  the  various  tests  performed  on  the  component 
during  the  manufacturing  process  serve  only  to  ensure 
conformity  with  the  software  model  resulting  from  the 
design  process. 
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Figure  3:  Design  and  prototype  block  diagram 


The  Validation 

The  Validation  phase  is  part  of  the  general  ASIC  design 
flow.  The  status  of  “validated  ASIC”  is  acquired  when 
all  the  requirements  listed  in  the  TRS  are  fully  satisfied: 

•  relatively  to  the  virtual  product,  by  using  simulation 
techniques, 

•  relatively  to  the  real  product,  through  an  overall 
validation  process. 


Qualification  of  the 
Technological  line 


VALIDATION 


Technology 


Figure  4:  Localisation  of  the  Validation 


Industrial  control  issues 

The  development  process  consists  of  a  number  of  stages 
leading  to  the  supply  of  ASIC  that  meet  the  requester’s 
requirements.  If  the  development’s  industrial 
environment  is  well  controlled,  development  may  be 
linear  and  culminate  in  the  expected  result.  Experience 
shows  that  the  process  is  disrupted  by  external  factors 
inherent  in  the  industrial  development  environment.  The 
“Development  process  control”  sets  out  ways  of 
controlling  that  process. 


It  allows  checking  the  complete  match  between  both 
virtual  and  real  products.  However,  the  founder  must 
qualify  the  technology,  the  manufacture  process  and  the 
libraries. 

The  virtual  product  is  the  result  of  the  structural  design 
phase.  It  includes  a  structural  netlist  but  also  the 
associated  test  vectors. 

The  real  product  is  the  result  of  the  manufacture  phase. 
In  the  guide,  this  chapter  only  covers  its  validation.  The 
verification  of  the  virtual  product  is  fully  described  in  the 
chapter  of  the  design  phase  as  it  is  usually  performed  by 
designers  or  by  a  specialised  team  closed  to  the  designers 
one. 


The  shaded  boxes  in  the  figure  5  indicate  the  scope  of 
industrial  control  in  relation  to  the  scope  of  the  guide  as  a 
whole. 

Control  of  contractors  is  based  on  the  principle  that  the 
development  of  ASIC  involves  a  succession  of 
complementary  specialities.  Those  may  be  found  within 
the  industrial  firm  developing  the  ASIC  or  among  its 
contractors.  To  ensure  proper  control  of  them,  a  dynamic 
mode  of  interfacing  must  be  established  between  the 
industrial  firm  and  its  contractors,  based  firstly  on 
principles  common  to  all  the  specialities  and  secondly  on 
particularities  of  certain  specific  fields  of  activity.  The 
specialities  are  grouped  around  four  main  areas  of 
activity: 

•  design, 

•  analysis  /  characterisation, 

•  manufacture, 

•  and  tools  /  libraries. 
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Control  of  the  production  technology  and  the  founder 

represents  an  unavoidable  special  case  in  the 
development  of  ASIC.  The  methodology  is  based  on 
general  control  of  manufacturers,  which  relies  on 
consolidation  of  the  aspects  of  quality  assurance  applied 
by  the  manufacturer: 

•  generic  qualification  of  combinations  of 
manufacturer  and  production  technologies, 

•  the  establishment  of  quality  contracts  between  the 
manufacturer  and  the  industrial  firm  which  is 
developing  the  ASIC. 

This  is  to  take  place  in  a  context  separated  from  the 
projects,  but  obviously  before  they  need  any  support 
from  the  founders.  At  this  point,  it  should  be  emphasised 
that  the  ASIC  designers  have  to  get  into  contact  with 
them  as  soon  as  possible,  that  is  at  the  beginning  of  the 
design  phase  in  order  to  make  sure  the  design  will  be 
fully  compliant  with  any  founders’  rules.  It  also  means 
that  any  internal  procedure  must  be  soft  enough  to  allow 
this  adaptation,  and  some  design  rules  must  be  set  up  to 
assure  portability  from  one  technology  to  another  one. 

Control  of  resources  centres  on  two  main  categories 
used  during  development  of  ASIC:  CAD  tools,  and  test 
resources  specific  to  ASIC.  In  the  case  of  the  CAD  tools, 
the  specific  aspects  of  those  that  are  technology- 
independent  and  those  that  are  dependent  on  a  particular 
technology  are  identified.  As  control  of  these  tools  is 
particularly  critical  to  ASIC  development,  a  number  of 
provisions  designed  to  limit  the  risks  they  generate  are 
presented  in  the  guide. 

Project  management 

The  lifetime  of  a  system  is  the  period  covering  the 
system’s  development,  refinement,  production 
engineering,  production,  delivery  and  maintenance. 

During  the  system’s  life  cycle,  ASIC  project 
management  traditionally  covers  development  of  the 
ASIC,  from  specification  of  the  circuit  (on  the  basis  of 
the  system  specification)  to  delivery,  validation  and 
qualification  of  the  prototypes. 

To  a  lesser  extent  it  also  covers  the  system-refinement 
and  production-engineering  phases  (through  the 
production  engineering  of  the  system’s  components). 

The  need  to  take  account  of  long-term  durability 
problems,  as  well  as  developments  in  technology  and 
design  techniques  naturally  means  that  ASIC  project 
management  has  implications  for  and  is  affected  by  the 
equipment  production  and  maintenance  phases. 

That  is  why  the  Consortium  has  chosen  to  put  into 
perspective  the  areas  of  concern  of  ASIC  design  team 
leaders  wishing  to  develop  their  activities  towards 
improving  the  service  provided  for  the  users. 

First  of  all,  in  the  light  of  the  “system”  or  “programme” 
view  of  project  management,  we  shall  define  more 
clearly  the  relationship  between  ASIC  development  and 


the  requesters’  needs  in  terms  of  visibility  and  assurance 
of  the  smooth  running  of  the  project.  This  will  lead  us  to 
define  the  modes  of  interfacing  between  a  project  team 
and  an  in-house  or  external  ASIC  design  centre. 

Therefore,  a  precise  distinction  is  to  be  made  between 
the  terms: 

•  “ASIC  project  management”,  which  designates  the 
management  of  a  team  designing  application- 
specific  integrated  circuits, 

•  “project  management”,  which  designates 
management  of  the  user  or  requester  projects.  The 
term  “requester  project”  should  be  understood  here 
to  mean  the  project  in  the  context  of  which  one  or 
more  ASIC  are  being  developed. 

In  addition,  the  Project  Manager  will  also  have  to  assure: 

•  the  relation  with  Purchase  managers  and  suppliers, 
in  particular  the  founder  and  tools  providers  to  get 
the  necessary  information  on  they  strategy 

•  the  relation  with  the  human  resources.  This  point  is 
one  of  the  most  important  as  the  consequences  of 
any  decision  have  short  but  also  long  term  impacts 

•  the  promotion  of  the  technology. 

Also,  the  Project  Management  is  involved  during  the 
BID  proposals. 

According  to  the  organisation  of  the  company,  one  or 
several  people  can  handle  all  these  aspects. 

Accommodation  of  Risks 

ASIC  technology  is  often  associated  with  a  high  notion 
of  risk...  This  issue,  however,  can  be  addressed  at  the 
design  level,  but  also  by  applying  a  rigorous  project 
management. 

ASIC  development  plan:  Management  -  ie. 
Minimisation  -  of  the  risk  associated  with  design 
necessitates,  ideally,  keeping  development  within  the 
strict  framework  of  the  team’s  area  of  know-how. 
However,  this  principle  frequently  conflicts  with  the 
need  to  adapt  that  area  to  respond  to  new  requirements  or 
to  apply  new  techniques  if  these  alone  will  allow  the 
planned  circuit  to  be  constructed.  At  all  events,  the  risks 
associated  with  the  particular  situation  of  the  ASIC 
contemplated  must  be  identified,  so  that  the  specific 
actions  to  minimise  those  involved  in  development  of  the 
ASIC  can  be  defined.  Such  analysis  is  necessary  to  lay 
down  and  refine  the  development  plan. 

Impact  on  cost:  The  general  principle  of  risk 
management  in  an  industrial  context  is  to  compare  the 
potential  cost  of  the  setbacks  that  may  be  suffered  as  a 
result  of  the  identified  risks  with  the  cost  of  specific 
actions  to  cover  them.  One  also  has  to  estimate  the 
probability  of  the  event  feared  occurring  and  the 
presumed  effectiveness  of  the  specific  action  envisaged 
to  avoid  the  setbacks.  These  estimates  are  generally  not 
strictly  quantifiable  and  must  be  based  on  past 
experience. 
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To  illustrate  this  principle,  the  quantity  of  work  involved 
in  validating  the  design  before  it  is  sent  to  the  founder 
must  be  measured  against  the  cost  and  impact  on  lead 
times  of  re-manufacture,  which  would  be  necessary  in 
the  event  of  an  error.  In  the  case  of  PLD,  the  absence  of 
specific  manufacturing  limits  this  risk. 

Impact  on  schedule:  Besides  the  frequently  direct  and 
considerable  impact  of  not  keeping  to  the  design 
schedule  on  the  development  cost  of  the  product  using 
the  ASIC,  other  indirect  and  equally  substantial  impacts 
may  be  attributed  to  poorly  controlled  design  time: 

•  reduced  profitability  of  the  project  through  late 
introduction  of  the  product  and  delayed  return  on 
investment; 

•  in  a  competitive  situation,  loss  of  market  share,  or 
more  directly  the  penalties  incurred  in  the  case  of  a 
pre-existing  order; 

•  loss  of  credibility. . . 

Ensuring  the  deadline  is  met  is  thus  a  specific  action,  and 
the  scale  of  the  effort  devoted  to  it  should  be 
proportionate  to  the  risk.  The  risk  is  all  the  greater,  as  the 
ASIC  is  frequently,  by  its  very  nature,  in  the  critical  path 
of  the  project  that  commissions  it. 

The  difficulty  of  this  task  arises  from  the  enforceability 
of  all  the  hazards  that  may  upset  the  smooth  progress  of 
design,  particularly  in  a  rapidly  changing  technical  field. 
In  addition,  there  is  extensive  dependency  on  third 
parties  (founders,  CAD  tool  suppliers,  etc),  that  limits  the 
total  control  of  timing. 

Impact  on  feasibility:  The  risk  of  discovering  belatedly 
a  problem  that  calls  into  question  the  very  feasibility  of 
the  intended  function  must  not  be  underestimated.  Its 
impact  on  cost  and  timing  is  direct  and  serious.  That  is 
why  the  feasibility  study  must  be  conducted  carefully 
and  must  culminate  in  both  a  TRS  and  a  technical 
solution  including  a  development  plan,  which  must  be 
fully  consistent  with  one  another.  Experience  is  therefore 
crucial  during  feasibility  analysis. 

Quality  and  Durability  assurance 

Quality  assurance:  The  description  of  the  process  of 
developing  an  ASIC  incorporates  activities  contributing 
to  ASIC  quality  assurance,  i.e.  primarily  helping  to 
confer  appropriate  confidence  that  the  ASIC  will  meet 
the  requester’s  requirements.  These  activities  are  those 
which  are  fully  integrated  with  current  development 
practices  and  which  it  would  have  been  artificial  to 
separate  from  the  other  stages  of  development.  Examples 
include  simulation  activities,  design  rules  verification, 
etc.  The  process  itself  as  defined  in  the  guide  thus 
already  has  a  quality  assurance  dimension. 

Other  major  topics  are  also  important  in  the  context  of 
ASIC,  such  as  industrial  control. 

Durability  assurance:  Obsolescence  in  ASIC  is  a 
constant  concern  for  industrial  firms,  as  technologies 
come  to  the  end  of  their  lives  and  others  no  longer  meet 


the  economic  criteria  of  the  market.  Manufacturers  are 
obliged  to  rationalise  their  means  of  production  to 
increase  their  profitability.  The  longer  the  period  over 
which  the  equipment  concerned  is  produced  and 
maintained,  the  more  critical  this  context  becomes.  In 
particular,  the  slightest  change  in  the  ASIC  or  the 
definition  of  the  item  of  equipment  necessitates  a 
qualification  process,  which  is  often  long  and  costly. 

A  set  of  coherent  recommendations  constituting  a 
method  of  ensuring  the  durability  of  an  ASIC  function 
can  be  proposed.  By  “function”,  we  mean  a  combination 
of  functional  behaviour  and  performance.  The  method 
relies  on  two  essential  levers  controlled  by  the  industrial 
firm:  the  choice  of  solutions  and  the  design.  The  object  is 
to  ensure  that  the  customer  continues  to  have  available  a 
system  meeting  a  requirement,  rather  than  a  system 
complying  with  a  definition. 

This  concept  of  durability  of  function  is  essential  to  the 
control  of  ASIC  durability.  It  forms  part  of  a 
customer  /  supplier  relationship  based  on  a  commitment 
as  to  results  and  on  definition  of  requirements  arising 
from  needs  at  each  level  of  complexity  of  the  system, 
down  to  component  level.  In  particular,  a  durability 
strategy  cannot  be  conceived  independently  of  the  rest  of 
the  system.  It  must  be  the  product  of  a  system  durability 
strategy  deployed  at  component  level. 

Durability  assurance  has  two  aspects: 

•  Preventive  action  to  ensure  durability  of  function: 
This  forms  part  of  the  initial  development  of  the 
ASIC  and  can  be  described  as  a  set  of  applicable 
recommendations  to  facilitate  re-design  of  the 
ASIC  and  maintenance  of  its  qualification. 

•  Action  to  deal  with  component  obsolescence  to 
make  sure  that  a  solution  is  available  to  ensure 
system  durability. 

It  may  be  noted  that  the  durability  of  an  ASIC  is  highly 
dependent  on  the  manufacturer’s  ability  to  ensure 
durability  of  the  production  technology,  i.e.  that  of  the 
component  and  the  function.  The  same  is  true  of  the 
choice  of  solutions  presented  above  as  one  of  the  levers 
essential  to  achievement  of  durability. 

Relationship  between  Quality  and  Durability 
assurance:  Quality  assurance  may  be  considered  to 
encompass  all  the  steps  taken  to  ensure  control  of  the 
development  process  and  the  achievement  of  a  solution 
satisfying  the  customer’s  requirement.  One  could  define 
its  ultimate  objective  as  fitness  of  the  solution  for  the 
purpose.  As  a  complement  to  that,  durability  assurance 
may  be  defined  as  all  the  steps  taken  to  ensure  the 
availability  of  solutions,  at  a  controlled  cost  and  within  a 
controlled  time,  that  satisfy  the  customer’s  technical 
requirement  throughout  the  life  cycle  of  the  function. 
The  ultimate  objective  in  this  case  is  the  availability  of 
suitable  solutions. 

The  figure  6  illustrates  this  principle.  Eor  a  given  ASIC, 
the  shaded  area  represents  the  provisions  to  be  put  into 
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effect,  with  no  regard  for  durability  requirements.  The 
upper  curve  indicates  the  provisions  to  be  put  into  effect 
to  cover  all  the  requirements,  including  durability. 

A  Provisions  to  be  implemented 
to  meet  the  customer's 
requirements 


DA  X. 


QA 


ASIC  A  ASIC  B  ASIC  C 

Figure  6:  Quality  assurance  vi.  durability  assurance 

The  scope  of  the  provisions  depends  to  a  large  degree  on 
the  requirements  relating  to  the  life  cycle  of  the  ASIC  in 
question.  In  the  figure  6,  ASIC  A  corresponds  typically 
to  a  long  life  cycle  (an  armament  programme,  for 
example),  ASIC  B  to  a  short  life  cycle  (with  no 
durability  constraints),  and  ASIC  C  to  an  intermediate 
life  cycle. 

Insofar  as  availability  of  solutions  that  meet  the  technical 
requirement  is  itself  one  of  the  customer’s  requirements, 
durability  assurance  could  be  considered  as  a  facet  of 
quality  assurance.  However,  as  durability  assurance  is  a 
relatively  new  concept  and  constitutes  one  of  the  guide’s 
major  concerns,  it  has  been  identified  and  dealt  with 
separately. 


The  HTML  version 

The  HTML  release  has  been  organised  in  such  a  way  that 
the  main  topics  are  directly  accessible  from  the  Welcome 
page,  as  shown  on  figure  7. 


Guidelines  related  to  quality  assurance  and  durability 
assurance  are  integrated  and  available  directly  inside  the 
ASIC  design  process  flow  with  the  help  of  following 


icons 


et 


.  Recommendations  dedicated  to 


programmable  logic  devices  are 


accessible  with 


Therefore,  it  allows  anyone  to  address  directly  one  (or 
several)  question(s)  without  the  needs  of  searching 
through  a  complex  process.  However,  it  remains  possible 
to  exploit  the  guide  in  a  very  linear  classical  way,  using 
the  guide  table  of  content. 


Conclusion  -  Deployement 

Given  that  such  a  guide  must  command  broad  acceptance 
and  be  validated  in  real  situations,  the  approach  to 
drafting  the  COCISPER  recommendations  is  based  on 
adhesion  through  utilisation. 

The  determination  to  interact  with  the  players  in  the 
ASIC  community  must  make  this  guide  a  living  tool, 
capable  of  adaptation  to  the  markets  targeted  and  to 
developments  in  technology  or  the  state-of-the-art.  The 
work  remains  compatible  with  existing  standards  (e.g. 
ISO  9000  /  AQAPIOO)  and  does  not  in  any  way 
represent  an  additional  constraint. 


Access  to  the  glossary 
Access  to  the  summary 

\ 


\ 


Access  to  the  main  topics 


COCISPER 

VenUm  2,0 


^  Conceyj/ion  Valuation  — 

^  'QJ  Maitrise  industrieUe  ' 


Novq  dedions  ce  guide  a  Michel  BARRE 
(Les  auteurs) 


2  ■  Le  guide 

3  •  La  Specification 
Technique  de  Besoin 

4  -  La  conception 

5  -  La  validation 

6  -  La  Specification 
d'utilisation 

7  -  L'exploitation 
industrielte 


Presentation  generale 

Introduction 

La  Direction  Generale  de  I'Armement  (PGA)  a  lance  un  projet  nomme  COCISPER  (Conception 
Circuits  Integres  Specifiques  Perennite)  qui  porte  sur  les  methodes  de  conception  des  ASIC 
(Circuits  Integres  pour  Applications  Specifiques)  et  sur  la  gestion  de  leur  perennite. 

Pour  mener  a  bien  cet  objectif,  un  Consortium  d'industriels  fran^ais  a  ete  charge  d'elaborer  un 
guide. 


8  •  La  maitrise  industrieUe 


Figure  7:  COCIPSER:  The  Guide  -  Welcome  page 
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Minimizing  the  Software  Re-design  in  Obsolescent  Radar  Processors  with 
Functional  Radar  Simulation  and  Software  Workshop 
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Abstract 


Signal  and  Data  Processors  are  the  sub-assemblies  which  are  the  most  likely  obsolescent  parts  in  modern  airborne 
Radars.  As  their  architecture  is  based  on  multiple  parallel  COTS  processors,  the  implementation  of  the  algorithms  in 
these  processors  is  a  costly  and  time  consuming  task  which  represents  the  most  significant  part  of  the  cost  when  the 
sub-assembly  has  to  be  replaced  due  to  component  obsolescence. 

The  use  of  a  powerful  software  workshop  is  the  way  to  dramatically  cut  the  cost  of  the  software  redesign  by  an 
extended  re-use  policy. 

A  significant  improvement  in  the  radar  development  cycle  can  be  achieved  through  simulation  techniques.  These  new 
tools  and  methodology  enables  to  reduce  costs  and  to  shorten  the  radar  modes  development  cycle. 

During  the  phase  of  specification,  a  functional  radar  prototype  is  developed,  requirements  are  defined,  and  testing 
procedures  are  developed.  This  functional  radar  prototype  is  completely  independent  of  the  processor  hardware  and 
survives  to  COTS  obsolescence. 

During  the  phase  of  on-board  functional  software  development,  the  functional  prototype  is  re-used  to  simulate  the 
machine  architecture  (processors  in  parallel,  communications,  ...)  and  the  algorithms  are  optimized  for  the  target 
processor  hardware. 

During  the  testing  phase,  a  cross  test  between  the  functional  prototype  and  the  on-board  functional  software  can  be 
performed  by  the  re-use  of  the  testing  procedures.  Also,  the  flight  tests  can  be  prepared  by  the  simulation  of  the  scenario 
to  be  played. 

The  designer  can  be  assisted  by  a  tools  for  all  this  developments. 


1.  Introduction 


New  radars  or  new  radar  modes  become  more  and  more  complex.  The  sophisticated  signal  processing  algorithms  and 
the  real  time  requirements  need  multiple  processors  machines.  To  reduce  the  cost  of  radar  development,  to  shorten 
development  cycles,  and  to  cope  with  obsolescence  problems  of  the  processor  hardware,  a  new  methodology  based  on 
simulation  and  re-use  of  simulation  software  is  applied  in  THOMSON-CSF  DETEXIS  for  some  years. 

The  main  means  of  this  new  methodology  are; 

further  use  of  simulation  techniques  in  the  phases  of  system  specification  and  design, 
re-use  of  simulation  software  modules  in  embedded  software, 
set  up  of  two  workshops  (simulation  and  processing  machines). 

In  a  classical  approach,  4  distinct  software  were  developed; 

advanced  studies  software  to  design  algorithms, 
function  modelling  software  for  radar  design, 
applicative  software, 

data  analysis  software  to  process  in-flight  recorded  data. 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 


9-2 


The  new  approach  consists  in  re-using  a  same  software  for  different  tasks.  In  fact,  3  out  of  these  4  software  run  on  a 
host  machine  (work  station);  the  software  used  for  prototyping  the  radar  can  be  exactly  the  same  as  the  software  for 
analyzing  the  in-flight  recorded  data.  The  software  for  advanced  studies  can  be  re-used  for  the  radar  design.  So,  on  the 
host  machine  (workstation),  we  can  have  a  single  software  (or  a  re-use  of  code).  This  software  being  completely 
independent  of  the  hardware,  it  is  not  affected  by  obsolescence.  For  on-board  software,  the  problem  is  quite  different  : 
this  software  runs  on  a  target  processor  which  implies  a  lot  of  constraints.  The  solution  is  to  re-use  the  software  running 
on  the  workstation  for  assisting  the  designer  to  develop  the  on-board  software  :  source  code  can  be  re-used. 

To  illustrate  the  simulation,  we  can  consider  a  3  phases  development  cycle:  specification,  on-board  software 
development,  and  validation. 


2.  Virtual  prototyping 

During  the  specification  phase,  simulation  can  be  used  for  prototyping  the  virtual  radar  on  an  host  machine 
(workstation).  This  radar  prototype  allows  to: 

•  design  the  functionality  of  the  radar  mode  and  to  define  the  interfaces  between  the  different  modules  of  the 
radar, 

•  specify  the  exact  algorithm  which  is  needed  (to  avoid  overspecification), 

•  evaluate  the  radar  performance,  such  as  resolution  for  an  air  to  ground  mode  or  detection  range  for  an  air 
to  air  mode, 

•  and  finally  define  the  validation  procedures.  The  prototype  software  is  verified  with  these  testing 
procedures,  which  are  the  functional  reference  for  the  radar  mode.  These  procedures  will  be  re-used  at  the 
validation  phase. 

This  virtual  prototype  is  independent  of  the  hardware  technology  and  is  represents  the  “reference”  of  the  radar. 

Then  the  designer  can  be  assisted  by  a  tool  for  the  development  of  the  radar  prototype  software:  a  tool  (such  as 
Ptolemy)  can  facilitate  the  designer’s  work.  A  toolbox  is  created  with  a  library  containing  signal  and  data  processing 
algorithms.  The  designer  can  build  the  prototype  and  takes  each  algorithm  he  needs  from  the  toolbox  and  then  links 
together  the  algorithms  with  a  specific  tool.  Then  on  workstation,  final  output  or  intermediate  output  can  be  verified. 
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RADAR  DEVELOPMENT  METHODOLOGY 


EXAMPLE  OF  FUNCTIONAL  MODEL  DESIGNED  WITH  PTOLEMY 


Example  of  functional  model  with  the  tool  Ptolemy 


3.  On-board  software  development  (new  hardware  design) 

The  second  main  phase  of  a  radar  mode  development  is  the  on-board  software  development.  With  the  virtual  prototype, 
a  signal  and  data  processing  software  is  available;  this  software  runs  on  workstation  (single  processor  environment).  At 
the  end  of  this  phase,  the  on-board  software  must  run  on  a  multi-processors  machine.  To  re-use  the  virtual  prototype 
software,  the  methodology  is  as  followed: 

•  in  a  first  phase,  a  model,  matched  to  the  processor  architecture,  is  developed  on  the  basis  of  the  functional 
model,  taking  into  account  the  architecture  and  the  characteristics  of  the  machine. 

•  in  a  second  phase,  each  algorithm  is  compiled  and  optimized  for  the  target  processor.  For  each  algorithm, 
the  number  of  cycles  and  the  memory  size  must  be  known.  This  is  possible  if  the  processor  accepts 
algorithm  in  a  language  such  as  C  or  C-H-,  . .  .which  is  the  case  of  new  COTS  DSP  or  processor. 

•  In  a  third  phase,  the  software  is  linked  and  loaded  in  the  target  machine  and  can  be  verified  on  the  test 
bench. 

This  methodology  is  of  interest  also  because  it  enables  the  designer  to  disconnect  the  problems  :  the  algorithm  problems 
are  seen  during  the  functional  model  development;  the  parallelism,  memory  mapping  or  communication  problems  are 
seen  during  the  development  phase  of  the  model  matched  to  the  target  architecture.  When  working  on  the  hardware  test 
bench,  all  these  problems  are  solved  and  the  designer  can  concentrate  on  real-time  problems. 

The  designer  can  be  assisted  by  tools  to  optimize  the  algorithms  implementation  on  processors.  For  example,  a  tool  can 
measure  the  workload  ratio  for  each  processor  or  evaluate  time  for  data  processing  .  Some  tools  also  generate  the  source 
code  for  each  processor  and  software  for  communication  between  processors  or  between  the  different  memories  of  a 
processor. 
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RADAR  DEVELOPMENT  METHODOLOGY 

TARGET  SOFTWARE  DEVELOPMENT  METHODOLOGY 


MethO 


dology 


FUNCTIONAL  SIMULATION  WORSHOP 


The  different  phases  of  the  on-board  software  development 


4.  Validation 


The  third  main  phase  of  a  development  cycle  is  the  validation.  During  this  phase  the  testing  procedures,  defined  at  the 
specification  phase  (and  run  on  the  functional  prototype  on  workstation),  are  played  on  the  radar  on  the  test  bench,  and 
the  both  results  can  be  compared.  By  that  way,  the  functional  requirements  can  be  verified. 

Always  in  the  phase  of  validation,  simulation  techniques  can  be  used  for  assisting  flight  tests. 

•  The  scenario  that  will  be  played  in  flight  can  be  played  first  on  the  virtual  prototype  on  the  host  machine.  So,  flight 
tests  can  be  prepared,  and  results  can  be  analysed. 

•  Simulation  techniques  allow  evaluation  and  validation  in  a  complex  environment.  For  example  it  is  possible  to  add 
on  recorded  data,  some  synthetic  data:  targets,  jammers... 


5.  Conclusion 


In  conclusion,  using  simulation  techniques  all  along  the  development  cycle  enables  to  design  the  functional  prototype  of 
the  radar  which  is  the  reference  of  the  radar  architecture,  modes  and  algorithms.  As  this  reference  is  not  technology 
dependant,  it  can  be  re-used  when  the  hardware  has  to  be  upgraded  minimising  the  redesign  and  validation  cost.  On  the 
other  hand,  libraries  of  algorithms,  subassembly  models  and  workshops  can  be  re-used  for  new  radar  product 
developments  to  design  the  new  functional  prototype.  It  also  helps  the  designer  to  develop  the  on-board  software,  to  do 
cross-testing  between  the  functional  prototype  and  the  on-board  software,  and  finally  to  prepare  the  flight  trials. 

A  cost  saving  (and  time  saving)  by  a  factor  2  to  3  has  already  be  demonstrated  either  for  new  developments  or  for 
processor  upgrades. 
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Summary: 

In  this  paper  the  author  will  present  the  arguments 
supporting  the  case  for  using  Commercial  Off-the-Shelf 
Software  and  Simulation  Tools  (COSST)  in  major 
defense  systems,  whether  for  actual  combat,  or  for 
embedded  training  purposes.  Whether  the  objective  is  a 
service  life  extension,  new  development,  or  an  upgrade 
to  certain  system  level  functions  and  operations,  COSST 
have  come  to  represent  the  solution  when  budgets  and 
time  scales  are  tight  and  engineering  staff  are  becoming 
harder  to  come  by.  The  author  will  describe  how  his 
company's  tools  have  been  layered  over  the  engineering, 
simulation,  test  and  analysis  processes  at  major  defense 
firms  to  improve  reuse,  assist  in  knowledge  capture,  and 
to  produce  results  in  major  weapons  systems  programs. 

Introduction: 

Virtual  Prototypes,  Inc  (VPI)  has  over  15  years 
experience  as  the  market  leader,  working  with  350 
corporations,  focused  on  the  successful  deployment  of 
Commercial  Off-the-Shelf  Software  and  Simulation 
Tools  (COSST)  in  the  Aerospace  and  Defense  and 
Automotive  industries.  Whether  the  objective  is 
Simulation  Based  Acquisition,  Lean  Manufacturing, 
Collaborative  Engineering,  Virtual  Product 
Development,  or  Synthetic  Environment  Based 
Acquisition,  COSST  have  come  to  represent  the  solution 
when  budgets  and  time  scales  are  tight  and  engineering 
staff  are  becoming  harder  to  come  by.  I  will  present 
today  some  of  the  economic  arguments  behind  the  move 
to  COSST  by  major  Aerospace  and  Defense  companies, 
and  how  the  VPI  Enterprise  Software  Eramework  (ESE) 
can  be  applied  to  the  engineering  process. 

In  the  past,  VPI  customers  successfully  used  one  or  more 
of  our  tools  on  numerous  programs.  Until  recently,  this 
has  been  the  norm.  With  human-machine  interfaces 
(avionics  and  vectronics  in  Aerospace  &  Defense 
(A&D),  vectronics  alone  in  Automotive)  becoming  an 
increasingly  virtual  product;  i.e.,  software  with 
performance  limited  only  by  the  computer  hardware 
environment,  it  is  becoming  important  to  capture  the 
knowledge  of  the  engineering  staff  involved  in  its 
creation.  Establishing  an  integrated,  common  set  of 
design  and  test  tools  with  VAPS,  ELSIM,  STAGE, 
SEQUOIA  and  third  party  products  from  companies  such 
as  Motorola  and  GreyStone  Digital  Technologies,  starts 


the  critical  process  of  knowledge  capture  and 
conservation.  This  process  is  contained  within  the 
system  development,  integration  and  test,  flight  test 
(A&D),  and  training  system  development  (A&D) 
functions. 

It  has  become  increasingly  clear  throughout  the  last 
decade  that  the  visualization  and  simulation  technologies 
embedded  into  the  VPI  virtual  prototyping  platforms  are 
in  direct  alignment  with  the  desired  goals  expressed 
within  strategic  business  initiatives  of  Aerospace  and 
Defense  and  Automotive  customers: 

•  Cost  reduction 

•  Schedule  compression  (Time  to  Market) 

•  Risk  mitigation  (Eocus  on  Target  Market 
Needs) 

•  Knowledge  capture  and  information  re-use 

Economic  Reality: 

One  may  ask  why  the  VPI  ESP  is  being  implemented  in 
these  companies?  Prom  the  VPI  perspective  and  its 
experience-base,  the  VPI  ESP  has  been  successful 
because  it  meets  the  strategic  business  initiatives  outlined 
above.  The  concept  has  been  proven  out  over  time.  The 
risk  of  implementation  has  been  significantly 
reduced/eliminated  as  a  result  of  VPI  successes  at  many 
customer  sites.  This  has  been  accomplished  in  many 
complex  VPI  customer  environments  such  as: 

•  Lockheed  (P-22,  C- 1 30,  MH-60,  P- 1 6) 

•  Elbit,  Litton  (SH2G) 

•  BAE/DASA/Alenia  (EPA) 

•  BAE/Boeing  (Wedge  Tail) 

•  Boeing  Bold  Stroke  (Avionics  Upgrade 
Programs) 

Interestingly,  the  motivations  to  implement  the  more 
streamlined  and  modern  VPI  ESP  process  were  typically 
driven  by  unrealistic,  if  not  suicidal,  timeframes  due  to 
the  inability  to  hire  personnel  coupled  with  the  untimely 
loss  of  key  subject  matter  experts.  We  have  repeatedly 
seen  highly  specialized  avionics  engineers  (e.g.  a  17-year 
veteran)  decide  to  start  a  new  career  at  a  ‘dot.com’ 
company  and  the  “avionics  expertise”  walked  right  out 
the  door. 
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We  know  these  vicious  stories  because  this  is  a  recurring 
theme  in  the  entire  defense  related  industry,  and  it  is 
beginning  to  spill  over  into  other  sectors  such  as 
Automotive.  We  have  witnessed  them  at  Raytheon, 

BAE,  Matra/BAE  missiles,  Alenia  and,  as  of  lately,  in 
MATRA/DaimlerChrysler  Aerospace  (EADS).  We  have 
personally  watched  this  breath-taking  exodus  injure  the 
quality,  and  knowledge  base  of  the  work  force. 

Expertise  continues  to  “walk  right  out  the  door”. 

VPI  has  built  its  business  model  precisely  around  this 
market  condition: 

We  want  to  help  customers  retain  expertise  through  the 
employment  of  the  VPI  ESE  and  achieve  their 
demanding  schedules.  We  deliver  a  solution  that  allows 
customers  to  maintain  a  reduced  staff  and  an  appropriate 
level  of  accumulated  expertise,  in  spite  of  the  exodus. 

We  are  interested  in  helping  our  customers  get  40%, 

50%,  60%  better  (e.g.l6  months  reduced  to  9  months, 
doing  the  work  with  300  engineers  instead  of  500, 
eliminate  re-work  in  software  code  development,  etc., 
etc.).  We  are  interested  in  shocking  the  system  to  a  new 
level  of  productivity  and  information  re-use. 

Getting  the  best  of  both  the  worlds: 

It  is  fully  recognized  that  that  our  customers  have 
developed  much  quality  custom  software  internally. 

This  includes  efforts  from  many  years  resulting  in  an 
array  of  models  for  flight  simulation,  radar,  navigation, 
etc. 

As  we  have  seen  however,  the  increasing  burden  of 
maintaining  both  the  topic-specific  software  and  the 
framework  that  houses  the  basic  components  has  become 
uncomfortably  expensive.  Most  of  the  framework  for 
legacy  software  has  not  been  migrated  to  modern 
programming  languages  or  new  computational  platforms. 
As  key  staff  member  attrition  takes  hold,  the  flexibility 
of  using  this  legacy  infrastructure  becomes  more  difficult 
daily.  The  situation  is  complicated  by  the  use  of 
government  created  software  tools,  which  may  also  be 
out-of-date  or  generally  are  awkward  to  manage/modify. 
These  conditions  have  driven  an  unstoppable  movement 
to  COSST-based  tools. 

Specifically,  how  does  a  customer  reap  the  benefits  of 
their  current  proprietary  efforts  and  the  benefits  of 
COSST? 

Rather  than  continuing  the  current  engineering  practice 
of  having  many  integrators  involved  in  various  parts  of 
the  system  development  process,  as  shown  in  Eigurel, 
Virtual  Prototypes,  Inc.  assists  customers  in  the  creation 
of  an  Integrated  Desktop  Prototyping,  Design, 

Simulation  and  Testing  Environment  (IDPDSTE)  as 
shown  in  Eigure  2.  Now,  several  large  customers  are 
moving  in  the  direction  of  using  the  entire  set  of  VPI 


tools,  in  a  flexible  framework,  to  respond  to  enterprise 
goals  such  as  LEAN  Engineering  and  Optimizing  the 
Value  Stream.  By  supporting  this  move,  VPI  is 
presenting  a  solution  that  benefits  many  programs 
throughout  the  life  cycle  of  each  program  and  its 
derivatives.  COSST  are  moving  out  of  the  realm  of 
"valuable  point-solutions”  to  “strategic  enterprise- 
solutions"  within  the  business  process. 


•  Multiple  Integrators 

•  Handing  Off  Without  Knowledge  or  Software  Reuse 

•  Limited  Collaboration 

•Trainers  Left  to  Figure  Things  Out  on  Their  Own 

Eigure  1  -  Existing  System  Development  Process 

The  proposed  solution  offered  by  VPI  allows  Customers 
to  get  the  best  of  both  worlds.  Eirst,  we  build  a 
framework  that  integrates  the  existing  subject  matter 
specific  software  into  a  common  and  modern 
architecture.  This  architecture  is  the  VPI  ESP.  It  is 
COSST-based  and  is  flexible  to  allow  for  changes 
through  time.  It  is  fresh  and  modern,  and  allows  for 
years  of  typical  framework  creation  to  be  accomplished 
in  a  few  months.  The  outcome  retains  the  valuable 
customer  legacy  development  efforts,  yet  inserts  these 
pieces  into  a  modern  and  contemporary  low-maintenance 
framework. 

The  result  is  that  customers  will  be  able  to  re-direct  their 
efforts  to  subject  specific  content  and  diminish 
involvement  in  software  maintenance  and  enhancement. 
The  engineers  will  do  the  engineering  and  VPI  software 
will  maintain  the  framework. 

It  is  interesting  to  note  that  almost  all  VPI  customers 
have  significant  investments  in  legacy  tools.  It  has  been 
shown  that,  in  spite  of  the  investment  in  that  area,  there 
are  significant  gains  that  can  be  incrementally  obtained 
by  further  automating  the  engineering  process.  This  is 
accomplished  by  implementing  the  VPI  COSST 
Pramework  and  leveraging  existing  legacy  models  (e.g. 
flight  simulation,  radar,  etc.). 
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necessary,  across  the  existing  avionics  life  cycle 
(software  development,  testing,  training)  engineering 
process.  The  aim  is  to  initially  shadow  the  existing 
customer  processes  and  overlay  the  tools  onto  the 
process  to  aid  in  the  knowledge  capture  process  as  shown 
in  Figure  2.  Part  of  the  emphasis,  as  shown  in  Figure  2, 
is  to  more  closely  integrate  the  Training  segment  with 
the  rest  of  the  processes,  shown  by  gray  arrow  across  all 
five  major  sub-integrator  blocks. 


Figure  2  -  Integration  of  Common  Tools  across  the 
Engineering  Process 

Re-using  Knowledge  and  Information: 

Reuse  of  Knowledge  and  Information  is  the  key  to 
success.  As  a  result  of  implementing  a  framework  that 
allows  for  information  re-use,  many  redundant  efforts  are 
eliminated  and  a  task  is  done  once  and  is  then  available 
for  access  in  future  months  and  years  by  other  groups.  It 
should  be  noted  that  this  continuity  and  information  re¬ 
use  is  possible  even  though  there  may  be  significant 
turbulence  in  staffing. 

Additionally,  the  VPI  Framework  allows  for  all  the 
knowledge  and  information  to  be  passed  along  the  Value 
Stream  in  a  contiguous  and  re-useable  manner. 

The  thought  of  a  new  framework  technology  that  allows 
for  dramatic  gains  in  the  triangular  management  of  time, 
cost  and  risk  will  not  be  received  well  by  all.  People  at 
many  levels  will  be  “protecting  their  local  empire”  and 
may  resist  this  proposal.  This  is  not  a  shock  to  us;  we 
see  it  daily. 

Other  groups  of  leaders  and  “change  agents”,  who  are 
interested  in  achieving  20-60%  improvements  and 
“shocking”  the  system  will  endorse  it.  We  have  done 
this  elsewhere  in  equivalently  complex  environments. 

As  much  as  those  who  are  protecting  their  empires  will 
argue  this  point,  it  is  fact,  and  is  not  a  debatable  topic. 
However,  during  these  transitional  times  when  empires 
are  being  protected,  the  need  for  high-level  management 
support  is  crucial. 

Process: 

Virtual  Prototypes  will  integrate  FLSIM,  STAGE,  VAPS 
and  our  other  software  products  into  an  enterprise 
framework.  The  purpose  of  the  integration  will  be  to 
create  a  seamless  integration  of  tools  permitting  the  early 
identification  of  design  problems,  reallocation  of 
requirements,  and  sharing  of  information  across  specific 
knowledge  domains  during  avionics  development.  This 
integration  will  focus  on  creation  of  a  desktop 
environment  focusing  on  integration  of  these  design  and 
test  tools,  with  existing  customer  proprietary  tools  where 


Code  Generation  Automation  and  Common  Test 
Environment: 

The  advantages  of  undertaking  this  effort  are  Code 
Generation  Automation  (CGA)  and  a  Common  Test 
Environment  (CTE)  from  Desktop  to  Simulator  to 
Aircraft.  The  advantages  of  code  generation  automation 
are  shown  in  Figure  3  and  include: 


Trainer/ 
Man-ln-the-loop 
Flight  Simulator 


Figure  3  -  Code  Generation  Automation  Advantages 

•  Retention  of  the  programming  knowledge  of  the 
program  as  mentioned  above 

•  The  ability  to  have  the  staff  focus  on 
optimization  of  the  value  added  tasks  such  as 
mission  critical  skills. 

Code  Generation  Antomation: 

Generation  of  code  from  the  tools  during  the  prototyping 
stage  of  development  provides  the  means  for  elimination 
of  rewrite  over  the  engineering  process  by  the 
furtherance  of  reuse.  Reuse  of  generated  code  ensures 
the  viability  of  code  before  integration  and  testing  and 
provides  a  means  of  up-front  validation.  The  visual 
nature  of  prototyping  with  tools  supports  the  "Art  to 
Part"  process  within  the  Virtual  Manufacturing 
paradigm.  The  tools  also  eliminate  the  present 
engineering  practices  of  reconstructing  the  code  at  each 
intermediate  process  of  the  project  life  cycle.  The 
inclusion  of  the  Design  Documentation  tool  with  VAPS 
increases  performance  by  permitting  the  automated 
generation  of  design  documents  for  use  throughout  the 
project  life  cycle  by  an  integrated  product  team.  The 
prototyping  tools  also  support  the  embedding  of  safety  of 
flight  critical  rules  prior  to  the  code  being  generated. 
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Figure  4  -  Code  Reuse 

Common  Testing  Environment: 

Additionally,  this  Common  Testing  Environment  brings 
a  level  of  consistency  that  has  been  missing  in  avionics 
development  in  the  past.  The  CTE  will  provide  for  reuse 
of  test  cases,  a  sort  of  data  fusion,  as  well  as  permit  the 
optimization  of  resource  utilization  during  testing  by 
reducing  or  eliminating  bottlenecks  in  scheduling  test 
resources.  The  CTE  supports  the  performance  of  full 
functional  testing  within  a  synthetic  environment.  The 
CTE  envisioned  by  the  integration  of 
VAPS/FLSIM/STAGE  creates  a  shared  test  environment 
that  can  be  reconfigured  for  each  process  (Figure  5).  The 
CTE  creates  a  repository  for  a  common  database  of  test 
cases,  thus  increasing  consistency  of  results  across  the 
process.  Eully,  a  20%  to  30%  reduction  in  support 
personnel  is  possible. 


Integrated,  Joint, 
Battlespace 
Simulation 
Environment  for 
Simulation, 
Testing,  and 
Analysis 


Eigure  5  -  Eully  Integrated  CTE  with  Synthetic  Test 
Environment 

Linkage  to  Support  and  Training  Systems: 

If  one  goes  back  to  Eigure  1,  it  is  shown  plainly  that  the 
Training/Support  Systems  portion  of  the  overall  Systems 
Development  process  has  no  clear  linkage  as  one 
traverses  prototyping  and  requirements  definition, 
hardware  and  software  integration,  integration  and 
testing  (including  flight  test),  and  system  testing. 
Training/Support  Systems  is  "left  to  fend  for  itself"  for 


design  information,  performance  data,  and  code.  Often, 
the  training  systems  designers  write  their  own  code  due 
to  a  lack  of  information  flow  and/or  to  maintain  a 
delivery  schedule  consistent  with  weapon  system 
delivery.  With  the  type  of  ESF  being  shown,  this  will  no 
longer  be  the  case.  The  Training/Support  Systems  group 
can  leverage  directly  from  the  knowledge  capture  taking 
place  across  the  system  development  process  through  the 
use  of  the  same  common  tool  set.  The  avionics  software 
will  be  identical  to  that  produced  during  prototyping  and 
requirements  definition  and  then  reused  throughout  the 
remainder  of  the  system  development  process  via 
automated  code  generation.  By  sharing  like  synthetic 
environments,  Training/Support  systems  will  be 
participating  in  the  knowledge  capture  process  and  will 
reap  the  benefits  of  code  and  database  reuse.  This  can 
provide  the  same  20%  to  30%  productivity  increases  as 
expected  in  the  overall  system  development  process. 
Eigure  6  depicts  the  expected  end-to-end  results. 


Eigure  6  -  End-to-End  Results  of  Utilizing  Code 
Generation  Automation  and  a  Common  Testing 
Environment 

How  the  VPI  ESF  Mitigates  Obsolescence  in  Defence 
Systems: 

Eirst,  the  VPI  ESE  is  composed  entirely  of  Commercial 
Components,  or  what  you  would  call  Commercial  Off- 
the-Shelf  (COTS)  software.  Second,  Human  System 
Interfaces  are  one  of  the  largest  drivers  in  any  weapons 
system  or  command  and  control  system  development. 
Third,  these  Human  System  Interfaces  frequently 
undergo  the  largest  number  of  modifications  or  upgrades 
in  the  life  cycle  of  a  system. 

By  using  tools,  which  generate  code  in  a  manner  that  can 
be  qualified  for  flight,  industry  and  government  will  save 
between  hundreds  of  thousands  and  millions  of  dollars 
upgrading  avionics  systems  in  the  future.  The  reason  is 
simply  the  fact  that  tools  will  eliminate  many  of  the 
tedious  hand  coding  steps  currently  performed  by 
engineering  staffs  today.  Other  benefits  of  tool  use  are 
the  ease  of  making  changes  and  reducing  risk.  Technical 
risk  is  reduced  through  machine  generation  of  the  code 
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(machines  do  not  get  creative).  Schedule  risk  is  reduced 
by  the  fact  that  code  generation  is  quicker  and  less 
expensive  than  hand  coding,  thus  a  shorter  schedule  can 
be  supported. 

On  July  24th  of  this  year,  Frost  &  Sullivan 
(http://www.frost.com)  published  a  report  indicating 
significant  upgrade  programs  in  the  military  avionics 
markets  in  the  United  States  and  Europe  would  lead  the 
industry  through  the  next  few  years.  Instead  of 
procuring  new  equipment,  air  forces  in  these  countries 
will  maintain  older  fleets  of  aircraft  while  investing 
much  of  their  budget  on  avionics  and  electronic  warfare 
upgrades.  Virtual  Prototypes  believes  its  tool  based  ESF 
solution  can  keep  these  upgrades  from  costing  more  than 
initial  estimates.  ESE  can  also  reduce  the  probability  of 


schedule  delays  and  diminished  functionality  upon 
delivery. 

Furthermore,  the  introduction  of  new  fighter  planes  and 
the  advent  of  Global  Air  Navigation  System/Global  Air 
Traffic  Management  will  drive  avionics  upgrades  in 
other  parts  of  the  world.  The  military  air  transport 
avionics  market  is  also  driven  by  the  need  to  upgrade  and 
develop  better  airlift  capabilities  around  the  globe. 

Recent  conflicts  have  demonstrated  the  vital  role  of 
airlift  in  military  operations.  Europe  and  United  States 
are  at  the  forefront  of  development  and  upgrade 
programs  for  their  fleets.  Virtual  Prototype's  believes 
that  without  a  robust  solution  to  the  brainpower  drain, 
these  countries  will  be  hard  pressed  to  complete  these 
upgrades  in  a  timely  manner.  Again,  the  ESF  solution 
can  help. 
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Summary 

Parts  obsolescence  was  affecting  all  Alenia  products  /  programs  so  that  we  had  to  identify  a  robust  strategy  to  prevent 
uncontrolled  effects. 

The  design  of  products  family  has  taken  the  obsolescence  management  issue  as  key,  basic,  requirement. 

The  basic  ideas  on  the  back  of  our  pro-active  approach  for  obsolescence  issues  are: 

All  products  (in  terms  of  equipment ,  subsystem  or  systems)  design  shall  offers  a  flexible  ,  open  architeture  which 
permits  to  change  a  specific  functional  block  maintaining  unchanged  the  overall  architecture. 

The  “Open  architecture”  used  shall  facilitate  any  design  changes  into  the  defined  functional  blocks  (caused  by 
obsolescence  issues)  because  of  the  high  level  of  interface  standardization. 

A  product  configuration  for  a  pre-determined  period  of  time  shall  be  maintained  by  performing  components  buy  for 
all  expected  production  batches  including  logistic  support,  allowance  and  spares. 

There  will  be  a  defined  periodic  Product  enhancement  which  permit  a  pre-planned  obsolescence  removal  activities 
and  relevant  design  changes. 

There  will  be  an  high  level  of  backward  compatibility  between  the  updated  system  configuration  and  the  previous 
one. 

Technologies  which  support  the  Product  enhancement  will  be  consolidated  and  introduced  at  a  point  where  the 
level  of  risk  is  considered  acceptable  (or  obsolescence  became  a  major  issue). 

There  will  be  a  “synchronised  technology  insertion  route”  defined  in  the  frame  of  the  Company  strategies  which 
takes  into  account  Customers  requirement  and  market  trend. 

The  obsolescence  removal  activity  can’t  be  “just  in  case”  but  need  to  be  anticipated  and  synchronized  with  a  new 
technology  insertion  phase  and  or  a  step  for  a  product  enhancement. 

There  is  an  absolute  need  for  a  company  organization  capable  of  provide  continues  market  survey  so  that  any 
corrective  action  can  be  taken  on  time  for  a  minor  changes  or  a  major,  synchronised  product  upgrade  change. 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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BACKGROUND 

Business  and  Products 

Alenia  Difesa  UBSA  is  a  branch  of  Finmeccanica  (the  major  Italian  company  in  the  high-tech  business)  in  charge  of 
developing  ,  producing  and  maintaining  electronic  equipments  ,  subsystems  and  systems  to  be  installed  on  fixed  and 
rotary  wings  aircraft. 

Since  60’ s  it  is  present  in  this  business  area  having  participated  to  the  major  European  programs  such  as  the  Tornado 
and  Eurofighter  aircraft,  the  EHlOl  and  NH90  helicopters  . 

The  Alenia  Difesa  UBSA  main  products  consist  of  Mission  and  Navigation  computers,  including  the  relevant 
Operational  Flight  Programs,  Displays  (Head-Up,  Head-Down,  Helmet)  and  all  simulation  and  integration  support 
systems  required  for  development  and  maintenance  of  the  on-board  avionic  systems. 


Introduction 

•  Obsolescence  is  an  industry  wide  problem:  it  is  in  general  not  new,  however,  the  rate  of  component  obsolescence  is 
increasing  rapidly  since  the  beginning  of  the  nineties. 

•  Military  component  manufacturers  are  consolidating  and  withdrawing  as  the  world  market  reduces.  The  reasons  for 
this  development  are  to  be  found  in  the  geopolitical  changes  of  the  nineties  and  the  Perry  Initiative.  In  1992  over 
72.000  Military  devices  were  available  -  by  1998  this  figure  was  38.000,  which  means  that  approximately  50%  of 
the  active  semiconductor  devices  available  at  the  beginning  of  the  program  development  phase  could  be 
discontinued  by  the  industry. 

•  As  the  specification  of  standard  components  increases,  the  requirement  for  military  components  decreases.  Today 
the  market  share  for  military  semiconductors  is  less  that  0.7%  compared  to  17  %  in  1976  and  7.5%  in  1986.  The 
market  situation  of  1997  has  become  worse,  and  further  manufacturers  have  discontinued  their  military  production 
lines. . 

•  Component  production  live  cycles  are  much  shorter  than  the  supported  lives  of  military  products. 

Whereas  the  system  life  cycle  of  a  military  aircraft  is  over  50  years  with  clearly  increasing  tendency  over  the  last 

decades  (as  shown  in  the  table  below). 


Aircraft 

In  service  since 

Phase  out  (projected) 

Useful  life^ 

F15 

1975 

201  Oh- 

35  years 

F14 

1973 

201  Oh- 

37  Years 

F4 

1972 

2010 

38  years 

UHl 

1959 

2004 

45  years 

Tornado 

1978 

2030 

52  years 

KC  135 

1957 

2017 

60  years 

B52 

1955 

2040 

85  years 

EF2000 

2001 

- 

- 

the  introduction  rate  for  new  microprocessors  today  is  two  years  and  new  memory  families  are  introduced  at  a  rate 
of  less  than  one  year. 

Moreover  the  introduction  of  new  logic  families  with  lower  supply  voltages  will  result  in  the  obsolescence  of  the 
entire  5V  technology  within  the  next  5  years. 


*  These  figures  do  not  include  the  development  phases  of  the  A/C  which  also  tend  to  increase  considerably  during  the  past 
decades 
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Definitions  and  abbreviations 


Obsolete 
Obsolescent 
Potential  Obsolescence 
Obsolescence 
Last  Time  Buy 

Life  Time  Buy 

Bulk  Obsolescence 
Life  Cycle  Code 


Tranche 


A  component  which  is  no  longer  manufactured. 

A  component  which  is  declared  to  become  obsolete  by  the  manufacturer 

The  fact  that  components  may  still  be  active,  however  obsolescence  is  expected  in  the  near  future 
The  process  of  becoming  obsolete 

Components  procured  to  secure  a  series  production  or  support  programme  after  manufacturer  has  notified  the  end  of 
production. 

Purchase  of  the  quantity  of  components  predicted  to  be  required  for  a  defined  period.  Mainly  used  for  risk  items  such  as 
ASICS,  connectors,  memories,  processors,  etc. 

A  large  number  of  complex  semiconductor  and  microcircuit  devices  on  one  SRI  have  become  obsolete. 

Each  active  device  have  assigned  a  Life  Cycle  Code  (ranging  from  1  to  5)  as  follows: 

1.  Introduction  The  component  (and  relevant  technology)  has  just  been  introduced 

2.  Growth  The  component  (and  relevant  technology)  has  established  a  market  position 

3.  Maturity  The  component  (and  relevant  technology)  has  become  industry  standard 

4.  Decline  The  component  (and  relevant  technology)  is  obsolescent  and  the  probability  of  a  manufacturer 

notification  to  become  obsolete  is  very  high 

5.  Phase  out  The  component  and  relevant  technology  is  obsolete 

Specified  quantity  of  “producf  ’  (LRU/SRU)  to  be  produced  during  a  specific  period  of  time 


Abbreviations 

A/C 

_ 

Aircraft 

ASIC 

Application  Specific  Integrated  Circuit 

BoM 

Bill  of  Material 

DRL 

Data  Requirements  List 

EAPF 

Engineering  Alteration  Proposal  Form 

ECR 

Engineering  Change  Request 

EF 

Eurofighter 

EFE 

Form,  Fit  and  Function 

FMECA 

Failure  Modes  Effects  and  Criticality  Analysis 

HW 

Hardware 

ECC 

Life  Cycle  Code 

ERI/U 

Line  Replaceable  Item/Unit 

ESA 

Logistic  Support  Analysis 

MTBD 

Mean  Time  Between  Defect 

MTBF 

Mean  time  Between  Failure 

OC 

Obsolete  Component(s) 

OMP 

Obsolescence  Management  Plan 

PCB 

Printed  Circuit  Board 

PI 

Production  Investment 

QML 

Qualified  Manufacturer  List 

QPL 

Qualified  Product  List 

RFQ 

Request  for  Quotation 

SP 

Series  Production 

SRI 

Shop  Replaceable  Item 

STTE 

Standard  to  Type  Test  Equipment 

SW 

= 

Software 
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Strategies 

A  Brief  overview 

Parts  obsolescence  was  affecting  all  Alenia  products  /  programs  so  that  we  had  to  identify  a  robust  strategy  to  prevent 
uncontrolled  effects. 

First  ,  we  had  to  establish  a  company  organization  (Human  resources  ,  methodologies  and  tools  )  able  to  support  a 
market  survey  activity  ,  to  provide  an  early  warning  information  to  the  project/program  management  team  ,  in  order  to 
decide  a  “cure”  or  a  “corrective”  action  ( i.e.  design  change,  last  time  buy  . . .). 

Second,  we  have  to  live  togheter  with  different  products: 

“old”  products  ,  still  in  production 
“new”  products  ,  in  development . 


Old  products 

We  were  not  in  position  to  change  “drammatically”  their  architecture. 

Consequently  we  were  only  able  to  monitor  the  market  and  to  apply  the  corrective  actions  when  obsolescence  issue 
arise  (i.e.  design  changes  “just  in  case”  several  last  time  buy  for  the  batches  still  to  be  produced)  by  adopting  the 
specific  company  organization  and  processes. 

We  considered  this  case  as  purely  “passive”  approach. 


New  Products 

We  have  had  the  opportunity  of  “new”  programs  for  which  we  had  to  build  a  completely  new  product  family. 

At  the  beginning  we  have  perfomed  a  market  analysis  looking  at  the  COTS  (Commercial  Of  The  Shelf  )  vendors  of 
electronic  modules/equipments  (i.e.  processor  modules,  chassis  . . .)  . 

Initially  use  of  COTS  provided  SRIs  have  been  considered  as  a  good  option  to  manage  obsolescence  but,  later  on,  we 
have  decided  to  design  our  own  product  families  since: 

*  the  vendors  of  COTS  modules  meet  with  the  same  obsolescence  problem, 

*  we  are  not  in  a  position  to  control  their  products  evolution  because  they  are  driven  by  different  market  (i.e.  the 
commercial  market), 

*  our  system  shall  offer  some  specific  capability  (environment ,  performance)  not  available  as  COTS  on  the  market, 

*  COTS  module  binding  us  on  the  “third”  party  for  our  business. 

The  design  of  such  “new”  products  family  has  taken  the  obsolescence  management  issue  as  key,  basic,  requirement.  We 
have  been  in  position  to  establish  a  “pro-active”  approach  also  considering  that  the  parts  obsolescence  problem  cannot 
be  resolved  once  and  for  all:  sooner  or  later  some  parts  became  osbolete. 

Having  in  mind  the  products  life  cycle,  we  focused  our  attention  on  the  fact  that  all  products  are  affected  by  periodic 
upgrades,  at  least  for  the  following  basic  reasons  : 

*  it  has  to  offer  the  best  trade  off  between  price  and  performance 

*  it  has  to  follow  the  technology  improvement  trend  and  the  relevant  market 
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Products  families 

On  the  base  of  our  previous  experience,  we  have  designed  a  state  of  the  art  product  families  based  on; 

*  advanced  design  criteria  (latest  technology,  software  development  tools,..) 

*  open  architecture  concepts  with  the  adoption  of  “COTS”  device  families 

that  gives  the  most  effective  benefits  with  respect  to  the  obsolescence  issues. 


Open  architecture 

Our  basic  view  is  that  obsolescence  can  be  controlled  properly  being  capable  of  porting  old  technology  into  a  new  one 
by  defining  an  Open  Architecture  on  which  the  core  components  are  under  our  direct  control  (Alenia  design)  or  are 
managed  with  an  adeguate  level  of  supplier  committment  (  key  suppliers  are  involved  directly  in  the  Alenia  Difesa 
product  strategy ). 

We  also  have  defined  a  deep  level  of  functional  standardization  (HW  &  SW)  which  permits  an  easy  ,  localized  and  well 
controlled  ( low  risk)  modification  ,  in  case  obsolescence  occours  . 

Several  definitions  and  solutions  are  applicable  in  realising  so-called  Open  Architecture . 

In  defining  our  “  interpretation”  we  have  considered  the  following  guidelines  as  “Basic”  design  requirement: 

*  the  system  architecture  shall  be  modular  and  scalable 

*  it  has  to  be  based  on  the  most  diffused  global  and  local  HW  interfaces 

*  it  has  to  be  logically  organised  in  “layers”  so  that  all  the  interfaces  between  different  layers  (  HW  &  SW)  shall  be 
clearly  identified 

*  the  HW  &  SW  layers  shall  have  “standard”  interfaces,  where  standard  means 

*  “most  diffused  and  supported  on  the  market” 

Therefore  we  have  organized  our  open  architecture  by  “clearly  identify”  the  following  : 

a)  functional  blocks  ,  over  standardized  local  bus  architectures: 

the  system  architecture  has  been  divided  into  functional  blocks  to  make  the  HW  layering  easely  interfaceable  by 
the  SW  layers. 

b)  local  bus  networks: 

PCI  communication  bus  has  been  selected  as  it  is  the  most  suitable  in  terms  of  market  availability  and  support 
(having  dominant  and  recognised  position  in  PC  architectures)as  well  as  it  is  offering  optimal  performance 

c)  global  bus  networks: 

VME  communication  bus  has  been  selected  as  the  most  suitable  in  terms  of  market  availability  and  support  also 
offering  optimal  performance 

d)  logical  &  physical  interfaces  (HW): 

Using  PCI  and  VME  buses  it  has  been  possible  to  define  EPGA/ASIC  based  communication  “bridges” 
between  functional  blocks. 

Logical  protocol  to  have  access  on  both  sides  of  each  functional  block  have  been  defined  and  standardised. 

The  functional  block  can  be  composed  of  discrete  devices  as  well  as  contained  into  a  single  VLSI  device  ( i.e. 
Hybrid  ,  ASIC  ,  LPGA) 

e)  API  (Application  5VT  to  Basic  Software  )  interfaces: 

Our  experience  has  demonstrated  that  software  packages*  development  and  certification  in  military  systems,  costs 
significantly  more  than  hardware  development  and  re-certification. 
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Therefore  key  target  was  to  minimize  impact  of  obsolescence  on  the  software  side  by  defining  : 

a)  a  robust ,  well  proven,  basic  software  to  operational  software  logical  interface,  based  on  COTS  operating  systems  . 

b)  a  standard  COTS  OFF  SW  factories  ( i.e.  VPI  VAPS  for  graphics  ,  ADA  for  OFP)  . 

*(Basic  and  Operational  Software) 

Design  criteria 

1.  The  Industrial  Grade  components  quality  level  is  largely  used  in  all  the  Alenia  Difesa  modules  .  This  increase  the 
equivalent  (pin  to  pin)  component  choices. 

2.  The  HW  modules  have  been  designed  with  the  key  requirement  of  technology  rationalisation  (reduced  amount  of 
connector  families  ,  reduced  set  of  device  types..) 

3.  Modular  approach  to  the  sub-module  has  been  encouraged  to  increase  HW  interface  robustness. 

4.  Packaging  optimisation  has  been  performed 

5.  Rationalisation  of  component  types  and  packages  has  been  defined 

6.  Topology  optimisation  has  been  identified  (  specially  for  analog  power  design) 


COTS  devices  in  Aienia  products 

In  designing  Alenia  products  we  have  identified  two  different  critical  levels  of  devices: 

a)  Key  Components  :  all  those  components  for  which  remove  obsolescence  means  larger  HW  re-design  with  significant 
impact  on  the  SW  (both  Basic  SW  and  Operational  Flight  Programs)  already  developed  and  certified. 

b)  Low  Level  Components  :  all  those  components  for  which  remove  obsolescence  results  in  a  “slight”  HW  modification 
possibly  without  impact  on  the  existing  SW 

Key  components  have  been  selected  considering  the  following  factors  : 

*  must  be  available  inside  the  commercial  market 

*  must  have  multiple  suppliers 

*  shall  comply  with  the  most  popular  backplane  buses  or  std  interfaces 

*  shall  be  available  at  least  in  the  “industrial  quality  level” 

We  have  classified  as  Key  Components  : 

a)  Processors  :  specific  contract  have  been  defined  with  the  main  Processor  suppliers  ( i.e.  Thomson  ,  Analog 
Devices. . .)  in  order  to  be  guaranteed  about  component  deliveries  for  all  the  Alenia  Difesa  programs. 

b)  ASICs  /  FPGA  :  this  components  have  been  developed  in  the  VHDL  language.  This  permit  an  easy  “migration”  of 
the  embedded  functions  from  an  old  technology  to  a  new  one  supporting  (if  required)  component  replacement. 

c)  CPLD  /  PLD  /  PAL  :  this  components  have  been  programmed  through  a  dedicated  tools  widely  used  on  the  market. 
This  permit  an  easy  “migration”  from  an  old  component  technology  to  a  new  one. 

d)  HYBRIDS  :  specific  contract  have  been  defined  with  the  main  suppliers  in  order  to  be  guaranteed  about  component 
deliveries  for  Alenia  Difesa  programs. 

e)  RAM  ,  EPROM  ,  EEPROM  :  We  have  identified  as  much  as  possible  most  diffused  components  on  the  market 
taking  into  account  those  devices  with  more  that  two  sources  and  any  potential  growth  in  terms  of  addressing  capability 
to  permit  an  easy  change  in  case  obsolescence  arise. 
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Company  organisation  and  toois 

Obsolescence  Management  requirements 

The  following  list  identifies  just  a  few  of  the  major  contractual  requirements  recurring  for  the  Obsolescence 
Management. 

(a)  Suppliers  (as  Alenia)  are  responsible  for  management  of  all  types  of  obsolescence  in  order  to  fulfil  their  contractual 
obligations  vs  the  Purchaser. 

(b)  Suppliers  will  make  arrangements  to  ensure  a  common  build  standard  is  maintained  throughout  each  production 
tranche  in  respect  of  obsolescence. 

(c)  There  will  be  a  phase  prior  to  the  commencement  of  each  production  tranche  to  prepare  for  a  common  Build 
Standard  for  that  tranche.  This  Build  Standard  shall  be  agreed  with  the  Purchaser. 

(e)  Interchangeability  at  module  level  shall  be  maintaned  troughout  a  production  tranche,  with  no  effect  to  the 
customer  technical  publications  or  in-service  maintainability. 

(f)  Any  Customer/Purchaser  change  requests  opportunity  shall  be  taken  to  concurrently  address  any  sensible  and 
practicable  associated  obsolescence  changes. 

The  above  requirements  are  satisfied  having  a  specific  Parts  Management  System  responsible  of; 

1)  Removal  of  all  existing  and  potential  obsolescence  prior  to  commencement  of  any  Series  Production. 

2)  Management  of  all  further  obsolescence  occurring  during  Series  Production 

Contractual  situations 

Two  different  contractual  situations  are  requested  to  Alenia  Difesa  to  distinguish  in  order  to  manage,  to  discover  and  to 
monitor  the  surge  of  the  obsolescence  in  any  LRU  design: 

•  Existing  Contracts 

•  New  Contracts 

Existing  Contracts 

For  the  existing  contracts  is  required  to  perform  the  following  activities: 

a.  To  maintain  the  existing  contract  conditions  and  to  acquire  the  components  with  the  same  Standard  shown  in  the 
relevant  Part  List. 

b.  To  detect  completely  and  exhaustively  the  components  obsolescence  at  the  initial  stage  of  the  design  to  avoid 
expensive  redesign  and  re-qualification  activities. 

c.  To  monitor  correctly  the  Obsolescence  taking  into  consideration  all  the  available  options  in  order  to  reduce  the 
impact,  saving  time  and  costs. 

d.  To  take  into  consideration  the  impact  of  the  quality  level  of  the  component  selected  during  redesign  and/or  re¬ 
qualification  activities  if  necessary 

New  Contracts 

For  the  New  Contracts  is  required  to  perform  the  activities  covering  the  following  aspects  : 

a.  Obsolescence  Free  Degree  (Obsolescence  tolerance) 

b.  Quality  Aspects 

c.  Equipment  Manufacturing  Process  (Process  Control) 

Summarising  for  the  New  Contracts  is  required  to  produce  a  Parts  Management  Plan,  linked  to  the  Obsolescence 
Management  Plan  which  reflect  the  adopted  policy  to  support  the  contractual  requirements  for  the  useful  life  of  the 
equipment. 
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Alenia  Organisation 

The  organisation,  management  and  responsability  of  the  activities  for  the  achievement  of  the  Obsolescence 
Requirements  is  delegated  to  the  Parts  and  Obsolescence  Management  Function  inside  of  the  Alenia  RMT/LSA 
Department. 

In  particular  the  Obsolescence  activities  are  managed  and  performed  by  the  personnel  of  the  above  mentioned  function 
with  the  co-operation  of  the  Department  involved  in  all  the  stage  of  project. 

The  engineers  appointed  to  the  Obsolescence  tasks  shall  have  access  to  the  design  data  and  drawings  as  required.  They 
will  be  involved  in  the  Project  Design  Review  meetings  as  appropriate  to  cover  the  Obsolescence  aspects  and  shall  be 
informed  of  all  proposed  design  changes. 

The  assessment  regarding  Obsolescence  and  Reliability  implication  shall  be  taken  into  account  prior  any  decision  on  the 
implementation  of  design  changes. 

The  Obsolescence  Focal  Point  will  interface  with  other  disciplines  correlated  with  LRI  Project.  Obsolescence 
information  will  be  supplied  to  Reliability  and  Maintainability  engineers  for  use  in  RMT  and  Logistic  Support 
Analyses. 

Close  contact  will  be  maintained  with  other  Engineering  disciplines  (e.g.  Design,  Manufacturing,  Purchasing)  and 
Program  Management  to  evaluate  the  impact  of  Obsolescence  issues. 

This  Focal  Point  is  responsible  to  co-ordinate  all  activities  related  to  the  Obsolescence  within  the  Alenia  Difesa  and  its 
Work-Share  Partners. 

An  inter-disciplinary  Obsolescence  Work-Team  is  established. 

The  members  of  the  team  are  members  of  all  involved  departments  such  as: 

•  Component  Engineering 

•  Procurement 

•  Design  Engineering 

•  Project  Manager 

•  Manufacturing 

•  Program  Manager 

The  Obsolescence  Work-Team  is  responsible  for  fact  finding  and  decision  making  in  critical  obsolescence  situations. 


Design  criteria  applied  to  minimise  obsolescence  impact 

To  minimise  the  impacts  of  the  obsolescence,  the  following  criteria  shall  be  considered  during  design  and  development 
phase  : 

1 .  Emphasis  shall  be  placed  on  the  use  of  components  for  which  multiple  sources  exist 

2.  Where  possible  all  components  shall  be  selected  from  preferred  part  list  as  Qualified  Part  List  and  Approved 
Component  Database 

3.  Use  of  standard  independent  development  environment 


Solutions  to  deal  with  Identified  Obsolescence 


Depending  on  the  on  the  LRIs  “Obsolescence  Health”  the  optimal  strategies,  recovery  actions  and  solutions  may  differ. 
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Solutions  may  be  classified  as  follows  : 


No. 

Strategy 

Description 

Application 

1 

FFF  equivalent 

Replacement  by  a  form,  fit,  function 
component 

Multi  source  component,  change  to  different  source,  no  real 
obsolescence,  problems  may  occur 

If  the  same  quality  level  is  unprocurable  a  substitution  shall  be  activate. 

2 

Life  Time  Buy 

All  components  for  the  series 
production  programme  (including 
spares  and  repair  stock)  will  be 
purchased  at  the  start  of  production 

High  risk  is  present  when  a  single  source  supplier  is  considered  in  the 
relevant  Part  List  (typical  for  ASICs  and  Hybrids). 

This  solution  is  to  be  avoided  when  possible,  it  can  be  applicable  when  a 
specific  batch  of  items  are  in  production  and  their  life  cycle  is  well 
known  and  agreed. 

3 

Last  Time  Buy 

Upon  obsolescence  notification  by 
the  supplier,  a  purchase  of 
components  is  initiated  to  cover  all 
future  demand  for  the  programme 
including  spares  and  repairs. 

This  solution  is  applicable  to  a  mature  equipment  and  on  isolated  events 
only,  but  not  for  new  design/re-design. 

It  is  also  acceptable  only  if  all  obsolete  components  on  a  module  can  be 
removed  by  last  time  buys,  otherwise  a  re-design  shall  be  considered. 

4 

Substitution 

Replacement  by  a  part  with 
acceptable  non-compliance 

This  solution  is  applicable  when  no  alternative  components  are  present 
and  a  deviation  can  be  accepted  by  the  Customer/Purchaser. 

No  re-design  activities  shall  be  considered. 

5 

After-market  Supplier 

Purchase  from  a  Supplier  who  has 
purchased  the  rights  and  facilities  to 
continue  to  manufacture  the  part 
from  the  original  Manufacturer. 

This  is  applicable  to  a  mature  equipment  and  on  isolated  events  only,  but 
not  for  new  design/re-design. 

6 

Emulation  /  Cloning 

FFF  redesign  of  the  obsolete 
component  using  current  technology 

This  is  applicable  to  the  ASICs  and  other  Custom  designed  components 
as  Hybrids 

7 

Redesign 

Re-design  of  the  entire  module  to 
replace  obsolete  components  with 
current  technology. 

Major  objective  is  to  remove  and 
avoid  future  obsolescence. 

This  is  applicable  when  bulk  obsolescence  can  be  predicted  or  when  at 
the  beginning  of  a  new  tranche  the  rules  are  out  of  last  time  buys 
conditions 

8 

Inventory  Survey 

Use  of  internet  tools  (such  as 
TACTech’s  Lo-K-tor)  to  locate 
components,  which  have  become 
obsolete  and  which  are  for  sale  as 
excess  inventory 

This  is  applicable  when  the  LRUs/SRUs  are  out  of  production  but  still  in 
service  (last  phases  of  the  life  cycle  of  the  equipment). 

Obsolescence  Activities  prior  the  Series  Production 

The  obsolescence  activities  to  be  performed  prior  to  the  Series  Production  shall  be; 

1 .  Obsolescence  Survey 

2.  Status  Assessment 

3.  Risk  Analysis 

4.  Removal  of  Identified  Obsolescence 
Obsolescence  Survey 

Alenia  Difesa  maintain  a  Parts  Management  System  which  allows  to  identify,  to  report  and  to  monitor  the  status  of 
actual  and  potential  obsolescence  arisings. 

The  purpose  of  the  Obsolescence  Survey  is  to  perform  on  each  LRI  the  following  activities  : 

a)  Active  monitoring  of  component  obsolescence  status  performed  by  the  responsible  organisational  entity,  according 
to  a  phase  model,  in  order  to  identify  components  that  are  approaching  the  end  of  their  life  cycle. 

The  phase  model  classifies  components  according  to  their  Life  Cycle  Code 

b)  Assigning  and  updating  the  obsolescence  status  code  to  all  components  based  on  the  monitoring  described 
under  a) 

C)  Maintaining  a  stock  management  policy  to  decide  on  life  time  buy,  last  time  buy  and  design-out  point,  involving 
consideration  of  costs,  alternate  sources,  lead-time  and  buy  opportunity. 
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d)  Planning  of  replacement/re-design  activities  including  the  assessment  of  alternative  technical  solutions  and  the 
associated  risk.  Sufficient  buffer  stock  will  be  built  up  to  avoid  production  schedules  being  compromised  by  re¬ 
design  and  qualification  activities. 

This  activity  includes  notification  to  the  Purchaser  as  well  as  to  all  Work-Share  Partners  involved. 

Awareness  of  actual  or  impending  obsolescence  problems  arises  from  a  variety  of  sources. 

These  incudes  : 

•  Manufacturers  and  Suppliers  Last  Time  Buy  Notifications 

•  Direct  inquiries  at  the  Supplier/Manufacturer 

•  Manufacturers  Web  Sites  by  Internet  Tools 

•  Notification  by  Consortium  Partners 

•  TacTech  Look-up  tool  and  TACTRAC  tool  (in  use  in  Alenia  Difesa  from  the  middle  of  1999). 

Inside  of  RMT/LSA  Department,  the  Component  Engineer  will  update  quarterly  the  obsolescence  status  of  all  LRIs 
active  components  by  using  TACTRAC  System  and  will  communicate  to  the  Project  Manager  and  Project  Leader  the 
obsolescence  status,  alerts  and  obsolescence  projections  of  the  last  design  Components  Part  List. 

The  result  of  the  obsolescence  survey  will  be  included  on  a  Quarterly  Obsolescence  Report  that,  for  each  component 
used  within  the  LRI,  will  report  as  a  minimum  the  following  information  : 

a.  Module  Identification 

b.  Alenia  Difesa  configuration  part  number  (as  foreseen  by  the  internal  Codification  Specification  System  and 
Component  Part  List) 

c.  Manufacturer  commercial  P/N 

d.  Manufacturer  Name 

e.  Total  quantity  used  on  the  SRU 

f.  Life  Cycle  Code  as  foreseen  by  TACTRAC  tool 

g.  Component  estimated  years  until  unprocurable 

h.  Component  estimated  years  until  obsolete 

i.  Source  of  the  information 

j .  Sourcing  Status 

k.  Obsolescence  Status  Assessment 

l.  Recommended  replacement  of  the  affected  components  including  the  availability  of  equivalent  components  and 
their  specification 

Status  Assessment 

Assessment  of  all  components  of  the  LRI  to  identify  known  and/or  expected  obsolescence  during  series  production  is 
performed. 

Basing  on  criticality  and  expected  consequences,  all  the  obsolescence  cases  are  classified  into  4  groups  as  follows  : 

criticality 

1 .  Replacement  available,  same  footprint  low 

2.  Replacement  available,  different  footprint(new  layout  is  required)  medium 

3.  No  direct  replacement  available,  different  functionality  high 

•  Design  modification  required 

•  New  layout 

•  Software  changes  could  be  required 

4.  No  direct  replacement  available,  process/technology  obsolete  (ASICs)  highest 

•  New  component  design 

•  Module  redesign 

•  New  layout 

•  Software 


This  classification  is  used  to  indicate  and  track  the  obsolescence  criticality  and  risk  in  the  “Obsolescence  Report”  for 
any  specific  program. 
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Risk  Analysis 

There  are  several  structured  reports  available  on  the  TACTRAC  Reports  Menu  that  Alenia  Difesa  use  to  perform  a  Risk 
Analysis.  They  are  : 

•  System  Life  Cycle  Matrix  Report 

The  Life  Cycle  Matrix  report  displays  information  that  shows  where  the  part(s)  in  the  selected  system  scope  falls 
into  Average  Life  Cycle.  When  assessing  the  heath  of  a  system,  looking  at  the  parts  that  fall  in  the  Introduction, 
Decline  and  Phase  Out  phases,  these  are  the  components  with  potential  reliability  or  procurability  problems  that 
need  solutions. 

•  Source  Depth  by  Product  Type  Report 

The  Source  Dept  by  product  Type  Report  breaks  out  the  selected  scope  by  part  family  (Diode,  Interface,  etc.)  and 
Manufacturer.  For  the  family  and  each  Manufacturer,  the  report  shows  how  many  parts  of  that  family  the 
Manufacturer  can  actilvely  supply  in  the  selected  system  scope,  according  to  the  approved  family/recommended 
replacements.  This  report  displays  the  number  of  parts  available  for  each  part  type  from  the  manufacturer 
indicating  also  which  manufacturers  you  may  be  able  to  obtain  better  price  from. 

•  Potential  Sourcing  Issue 

The  Potential  Sourcing  Issue  Report  displays  all  parts  that  currently  have,  or  could  shortly 
have,  a  problem  with  Manufacturer  availability  according  to  a  specific  selected  filter. 

The  reports  displays  parts  if  they  fall  into  any  of  the  following  categories  according  to  the  filter  criteria: 

>  No  Source-  Obsolete  means  the  part  and  its  recommended  replacements  have  no  active  sources  of  supply 

>  No  Source-Unprocurable  means  the  part  has  no  active  sources  of  supply  but  at  least  one  of  its  replacement  does 
have  active  source  of  supply 

>  Single  Source-Unprocurable  means  the  parts  has  no  active  sources  of  supply  and  its  replacements  have  only  one 
active  source  of  supply 

>  Single  Source-Procurable  means  the  part  has  only  a  single  source  of  supply 

>  Life  Buy  means  the  part  is  under  Life  Time  Buy  status  and  will  no  longer  be  available  in  a  short  period  of  time 

>  Inactive  for  New  Design  means  the  part  has  been  determined  by  DSCC  to  not  recommended  for  new  design 

•  Active  Alternates  List  by  Quality 

The  Active  Alternates  List  by  Quality  Report  displays  any  active  alternates  from  parts  based  on  the  filter  for  parts 
in  the  Selected  System  Scope  broken  down  by  Quality  Level.  With  this  report  is  possible  to  see  which  parts  in  the 
system  have  the  most  alternatives  and  how  many  alternatives  exist  at  each  Quality  Level. 

•  Active  Alternates  List 

The  Active  Alternates  List  Report  displays  the  number  of  active  and  inactive  alternatives  for  parts  selected  by 
system  scope.  To  assess  the  health  of  the  system,  it  is  necessary  to  look  at  the  usage  in  the  system  in  relation  to  the 
number  of  active  and  inactive  alternatives. 

These  reports  are  very  useful  in  gauging  any  potential  risk  in  supporting  the  System  from  an  obsolescence  and 
manufacturer  availability  standpoint. 

Alenia  Difesa  uses  these  TACTRAC  facilities  to  perform  Risk  Analysis  for  the  LRIs. 

Removal  of  Identified  Obsolescence 

All  the  identified  obsolescence  reported  on  the  LRI  Quarterly  Obsolescence  Report  shall  require  a  recovery  action. 

The  recovery  actions  may  be  several  as  follows: 

a)  Replace  the  obsolete  component  by  replacement/redesign  activities. 

The  replacement/redesign  activities  for  replace  obsolescent  components  shall  maintain  unchanged  the  original 
interface  at  LRU/SRU  level  in  accordance  with  the  interface  specification. 

For  the  above,  the  interchangeability  at  Form,  Fit  and  Function  (FFF)  level  of  the  previous  version  of  SRU  with 
the  new  version  will  be  guaranteed. 

The  new  component  selection,  selected  to  replace  the  obsolescent  one,  shall  be  determined  taking  into  account  the 
following  characteristics: 

•  Clear  technological  longevity  and  maturity 

•  Multiple  Sources 

•  Market  position 
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When  alternative  components  have  been  identified  they  will  be  included  into  Quarterly  Obsolescence  Report  with 
the  following  information: 


1 .  The  commercial  p/n  and  Manufacturer  name. 

When  the  alternative  component  is  a  multiple  source,  the  commercial  p/n  and  name  of  each  Manufacturer 
shall  be  reported. 

2.  Which  obsolete  component  will  be  replaced  by  the  new  one 

3.  The  compatibility  level  respect  the  component  to  be  replaced  as: 

•  Pin  to  Pin  compatible 

•  Function  compatibility 

•  Not  full  compatible 

When  not  full  compatible,  the  redesign  at  SRU  level  will  be  analysed  in  more  details  taking  into  account  the  practices  to 
be  adopted  in  using  the  new  component  and  relevant  technology. 

This  process  captures  the  logic  of  Large  Scale  Integration  microcircuits  such  as  microprocessors,  microcontrollers, 
arithmetic  logic  units,  PALs,  FPGAs,  EPLDs  etc.  In  that  cases  the  Quarterly  Obsolescence  Report  will  be  updated 
including  all  the  components  that  have  been  impacted. 

4.  The  impact  on  the  qualification  status  of  the  LRI 

5.  The  Status  level  of  the  new  components  including  : 

•  Multiple  Sources 

•  Technological  maturity 

•  Adequate  Life  Cycle  Code 

b)  Provide  a  Last  Time  Buy  action 

When  a  Last  Time  Buy  action  is  considered  then  the  future  requirements  will  be  estimated  and  the  total  buy  cost 
calculated.  Holding  costs  will  be  included  in  the  cost  estimates.  Since  Last  Time  Buys  are  time  limited  the 
response  time  to  implement  will  be  the  shortest  and  the  relevant  due  date  will  be  reported  and  timely  controlled. 
Where  a  Last  Time  Buys  are  employed,  a  procedure  will  be  developed  to  control  the  long-term  storage,  life  refresh 
and  health  of  the  component  or  die. 

After  that  the  latest  date  of  the  Last  Time  Buy  has  been  verified,  the  quantity  to  supply  will  consider: 

•  The  quantity  to  support  the  Production  Investments  (PI) 

•  The  quantity  to  support  the  Series  Production  phase 

c)  Procure  Obsolete  Components 

When  a  component  have  become  obsolete,  procurement  of  such  part  could  be  achieved  by  After-Marked  Suppliers 
from  stocks  or  other  searching  methods. 

d)  Life  Time  Buy  of  Critical  components 

For  components  which  have  been  identified  as  being  critical  the  following  conditions  shall  be  verified: 

1 .  The  latest  date  of  the  Last  Time  Buy 

2.  The  quantity  of  components  required  to  : 

•  Support  the  Series  Production 

•  Support  activities  to  protect  the  relevant  LRI  program 
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Documentation  and  Data  Requirements  List  (DRL) 

Design  documentation  and  DRLs  updating  required  as  a  result  of  re-design  activities  shall  be  defined  in  the  respective 
EAPF. 


Obsolescence  Management  during  Series  Production 

Approaches 
Reactive  Approach 

The  reactive  approach  deals  with  obsolescence  upon  occurrence.  It  makes  no  specific  provisions  for  obsolescence 
which  may  occur  in  the  future.  However,  obsolescence  may  occur  and  will  upon  occurrence  raise  cost.  This  approach 
constitutes  a  high  risk  on  the  side  of  the  Purchaser,  because  the  impact  of  future  obsolescence  is  not  known  and  a 
budget  cannot  be  set  aside. 

Proactive  Approach 

The  Proactive  approach  is  similar  to  an  insurance  policy  and  its  objective  is  to  reduce  the  costs  in  managing  the  LRI 
Unit.  For  the  above  Alenia  Difesa  offers  insurance  against  obsolescence. 

The  Alenia  Difesa  Obsolescence  Management  is  based  on  the  proactive  approach. 

Alenia  Difesa  IQB0426  internal  procedure  defines  the  process  and  procedure  which  shall  be  used  to  monitor  the 
obsolescence  status. 

The  obsolescence  activities  to  be  performed  during  the  specific  FRI  Series  Production  shall  be: 

Obsolescence  Monitoring 
Corrective  Actions 
Risk  Analysis 


Anticipated  Extent  of  future  Component  Obsolescence 

Assessment  of  the  development  phase  results  of  the  existing  design  identifies  all  components  that  are  already  obsolete 
or  will  become  obsolete  shortly. 

A  prediction  of  the  non  availability  of  components  can  only  be  based  on  known  technology  and  market  trends. 

Such  prediction  of  the  ’’health  status”  are  based  on  the  Fife  Cycle  Codes  (FCCs)  and  relevant  availability  in  terms  of 
“In  Production”  or  “Not  in  Production”  data  of  components  with  respect  to  obsolescence. 

These  component  FCCs  are  associated  with  the  their  anticipated  family  type  life  span. 

As  described  in  section  1.5  the  FCCs  are  provided  by  the  TACTRAC  system  of  TACTech  database. 

This  online  and  real  time  Obsolescence  Management  Tool  provides  on  request  a  preview  of  the  Health  Status  of  an 
SRU  such  as  a  PCB  for  the  life  span  of  the  FRI  or  any  other  time  span. 

Obsolescence  Monitoring 

If  potential  obsolescence  becomes  known  fairly  in  advance,  the  necessary  measures  may  be  taken,  and  major  problems 
can  be  avoided  at  an  acceptable  cost  level. 

The  objective  is  therefore  to  conduct  “Proactive  Obsolescence  Management”  as  opposed  to  “Reactive  Obsolescence 
Management”  . 

Obsolescence  Monitoring  activities  shall  be  carried  out  during  Series  Production  to  establish  the  obsolescence  status  of 
the  FRI  and  relevant  SRUs. 

In  the  following  sections  are  described  the  facilities  which  will  be  used  to  perform  this  task. 

TACTech  Database 

Tactech  database  provides  information  on  the  component  status.The  information  consists  on  an  indication  of  where  the 
component  function  and  related  technology  is  in  its  lifecycle  and  what  alternatives  are  available  including  information 
relevant  to  direct  replacements  down  to  commercial  or  industrial  grade  equivalents. 

Commercial  database 

When  a  component  has  become  obsolete  and  why  it  has  become  obsolete  no  consistent  and  complete  database  is 
available  at  Alenia  Difesa.  In  these  cases  a  lot  of  Commercial  database  on  WFB  Sites  are  available  and  consultable  to 
determine  the  obsolescence  status  and  availability  of  the  component  under  analysis. 

This  kind  of  information  will  be  managed  and  filed  by  the  Obsolescence  Focal  Point  within  Alenia  Difesa. 
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Manufacturer  Notification 

In  most  cases  the  obsolescence  is  detected  when  procurement  is  required.  This  occurs  for  those  items  purchased  in  small 
quantities  from  distributors  and  Alenia  Difesa  just  receives  a  notification  that  the  component  in  question  will  become 
obsolete  and  a  Last  Time  Buy  frequently  is  offered. 

Alenia  Difesa  is  strongly  avoiding  this  kind  of  notification  as  a  reactive  approach  sensitising  continuously  the 
Manufacturers  in  giving  these  information  as  a  proactive  approach. 

However  this  kind  of  information  will  be  managed  and  filed  by  the  Obsolescence  Focal  Point  within  Alenia  Difesa. 
TACTRAC  Tool 

TACTRAC  tool  will  be  used  during  the  LRI  Series  Production  as  a  support  tool  for  obsolescence  management. 

It  is  also  noted,  that  various  European  Companies  involved  in  EF2000  Programs  have  already  subscribed  to  TACTRAC 
and  are  using  the  service  successfully. 

Alenia  Difesa  is  using  the  TACTRAC  tool  (installed  in  April  1999).  The  system  is  based  on  a  component  data  base 
which  is  kept  current  by  the  service  provider. 

The  main  TACTRAC  features  are: 

(1)  Constant  electronic  monitoring  of  BoMs  with  real-time  discontinuance  notification.  All  areas  of  procurement 
vulnerability  in  a  bill  of  material  are  automatically  identified  and  prioritised.  A  full  analysis  of  sourcing  depth  is 
provided  and  areas  of  sourcing  vulnerability  are  identified.  Furthermore  the  system  provides  immediate 
notification  alerts  on  military  microcircuit  discontinuance  and  automatically  notifies  the  user  if  any  sourcing 
change  occurs  in  the  bill  of  material  be  it  a  new  source  or  loss  of  a  source. 

(2)  Automated  real  time  electronic  (living)  library  of  semiconductor  availability 

The  component  library  provided  contains  virtually  all  known  military  microcircuits  as  well  as  their  industrial 
and  commercial  grade  equivalents.  This  library  is  constantly  updated  with  information  received  directly  from 
all  QPL/QML  manufacturers. 

Detailed  parametric  data  are  available  on  all  of  the  approximately  200.000  individual  devices  in  TACTech 
database. 

(3)  Identification  of  critical  items  such  as  LRUs,  SRUs,  ASICs  and  components  driving  obsolescence. 

(4)  Life  Cycle  modelling  at  both  the  component  and  configuration  level. 

Preventive  obsolescence  management  involves  component  selection  and  equipment  level  analysis,  that  takes 
into  consideration  component  life  cycles.  Based  on  the  technology  attributes  of  the  device  being  assessed,  life 
cycles  are  calculated  and  maintained  for  each  device  in  a  “living  library”. 

(5)  Real  time  component  procurability  monitoring 

(6)  Procurement  problem  identification  with  solution  alternatives. 

(7)  Automated  data  retrieval  and  analysis  techniques  for  determination  of  the  best  possible  solution. 

(8)  Configuration  management  flexibility  to  analyse  a  single  SRU  or  to  roll  up  multiple  system  or  program 
combinations. 

(9)  Automatic  Indenturing  capability  to  identify  discontinuance  impacts  at  the  component,  LRU  and  SRU. 

(10)  Cross  reference  of  all  military  microcircuits  to  industrial  and  commercial  grade  equivalents.  All  military 
semiconductor  devices  as  well  as  all  cross  reference  equivalents  reside  within  the  library.  This  allows  to  identify  all 
FEE  equivalent  parts  in  descending  order  of  quality. 

(1 1)  Parametric  part  search  capabilities 

In  selecting  a  device  for  a  particular  application,  an  appropriate  part  can  be  selected  without  knowledge  of  the 
manufacturer’s  part  number.  The  system  allows  the  user  to  identify  the  part  by  key  parameters  only  for 
parametric  searches.  All  parts  meeting  the  input  criteria  are  identified  in  complete  technical  detail  inclusive  of 
life  cycles  and  sourcing  availability. 
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(12)  Access  to  an  electronic  marketplace  for  hard  to  find  components 

(13)  Data  sharing  among  linked  users  on  corporate  level  (or  within  other  structures)  to  enable  co-ordinated  decisions 
and  cost  sharing  and  to  avoid  task  redundancy 

Corrective  Actions 

The  information  obtained  from  Obsolescence  Monitoring  shall  be  used  to  perform  the  recovery  actions  to  be  reported  in 
the  updated  Quarterly  Obsolescence  Report. 


Conclusion 

The  basic  ideas  on  the  back  of  our  pro-active  approach  are: 

The  products  (in  terms  of  equipment ,  subsystem  or  systems)  design  shall  offers  a  flexible  ,  open  architeture  which 
permits  to  change  a  specific  functional  block  maintainig  unchanged  the  overall  architecture. 

The  Open  architecture  shall  facilitate  any  design  changes  into  the  defined  functional  blocks  (caused  by 
obsolescence  issues)  because  of  the  high  level  of  interface  standardization.  The  product  design  shall  be  so  open  and 
modular  to  permit  changes  and  update  with  a  reasonable  level  of  risk  and  cost. 

A  product  configuration  for  a  pre-determined  period  of  time  shall  be  maintained  by  performing  components  buy  (at 
least  for  the  key  components)  for  all  expected  production  batches  including  logistic  support,  allowance  and  spares. 
During  that  period,  the  Customer  shall  be  guaranteed  by  Alenia  Difesa  against  any  obsolescence  issue  by  applying 
a  “Last  Time  Buy  per  Batch”  policy  and  equipment  re-design,  where  necessary  (minor  changes  due  to  “low  critical 
level  components”  obsolescence). 

There  will  be  a  periodic  Product  enhancement  (Production  Batch  by  Production  Batch)  which  also  permit  a  pre¬ 
planned  obsolescence  removal  activities  with  relevant  design  changes. 

There  will  be  an  high  level  of  backward  compatibility  between  the  new  ,  updated  ,  system  configuration  and  the 
previous  one  .  The  Customer  is  taken  aware  about  any  difference  by  using  a  very  efficient  and  transparent 
configuration  control  system. 

Technologies  which  support  the  Product  enhancement  will  be  consolidated  and  introduced  at  a  point  where  the 
level  of  risk  is  considered  acceptable  or  obsolescence  became  a  major  issue. 

There  will  be  a  “synchronised  technology  insertion  route”  defined  in  the  frame  of  the  Company  strategies  which 
takes  into  account  Customers  requirement  and  market  trend. 

The  problem  of  parts  obsolescence  can’t  be  solved  as  a  one  shot  event  .  It’s  control  and  management  has  to  be 
considered  as  an  essential  requirement  for  an  high  quality  product. 

The  obsolescence  removal  activity  can’t  be  “just  in  case”  but  need  to  be  anticipated  and  synchronized  with  a  new 
technology  insertion  phase  and  or  a  step  for  a  product  enhancement. 

There  is  an  absolute  need  for  a  company  organization  capable  of  provide  continuos  market  survey  so  that  any 
corrective  action  can  be  taken  on  time  for  a  minor  changes  or  a  major  ,  synchronised  product  upgrade  change. 
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Summary 

The  increasing  discrepancy  between  the  life  cycles  of  professional  electronics  equipment  and  the  life  cycles  of  the 
components  (which  are  largely  intended  for  volume  markets)  means  that  professional  electronics  manufacturers  must 
implement  methods,  processes  and  tools  to  give  their  customers  long-term  availability  guarantees  for  their  products 
despite  obsolescence  problems  in  the  components. 

Although  this  effort  must  be  made  at  the  level  of  each  unit  and  adapted  to  the  type  of  product,  the  customers’  needs  and 
internal  organisation,  the  existence  of  common  methodological  tools  and  principles  can  significantly  help  each  unit  set 
up  the  appropriate  procedure  for  their  particular  case. 

This  paper  gives  an  overview  of  the  methods  and  tools  set  up  within  the  Thomson-CSF  group  to  support  the  units  in  this 
procedure. 

These  can  be  split  into  four  levels,  which  correspond  to  increasing  maturity  of  the  obsolescence  risk  control. 

Level  1  :  curative  level  (during  production  and  use  phases). 

Level  2  :  downstream  preventive  level  (also  during  production  and  use  phases). 

Level  3  :  upstream  preventive  level  (during  development  phase). 

Level  4  :  upstream  preventive  level  (during  design  phase). 

Finally,  it  asserts  that  controlling  obsolescence  and  being  able  to  guarantee  the  long-term  availability  of  equipment  is 
now  a  major  part  of  the  professional  electronics  manufacturer’s  job,  and  is  an  increasingly  important  factor  in  meeting 
customers’  needs. 


1.  An  irreversible  change  requires  a  response 

The  problem  of  obsolescence  suddenly  took  on  significant  proportions  during  1993  and  1994.  In  reality,  it  is  a  much 
older  phenomenon  (it  has  always  existed  right  from  the  origin  of  the  components).  However,  up  to  1993-1994,  the 
professional  electronics  world  (manufacturers  and  customers)  let  itself  think  that  it  was  a  minor  problem  that  could  be 
solved  easily  in  production  centres  by  replacing  the  obsolescent  component  by  another  functionally  equivalent 
component. 

Three  events,  the  effects  of  which  came  together  in  1993-1994,  significantly  increased  the  scale  of  the  phenomenon  and 
the  seriousness  of  its  consequences,  and  gave  rise  to  a  radical  questioning  of  the  processing  methods  previously  used. 
These  three  events  were: 

1)  the  gradual  loss  of  influence,  on  the  semiconductors  market,  of  long-cycle  professional  electronics  industries 
(aerospace,  space,  defence,  industrial  control)  in  favour  of  short-cycle  consumer  industries  (computer, 
telecommunications,  multimedia).  Below  the  crucial  10%  threshold,  the  long-cycle  industries  were  no  longer  an 
attractive  outlet  for  the  semiconductors  industry,  which  was  seeing  an  explosion  in  its  market  (+20%  per  year); 

2)  the  DoD’s  announcement  of  its  intention  to  promote  the  use  of  dual-use  technologies  (see  [1])  wherever  possible 
and,  consequently,  in  the  field  of  components,  to  target  its  aid  on  absolutely  vital  components  in  defence 
equipment.  Several  semiconductor  manufacturers  then  decided  to  stop  producing  MIL-883  components.  As 
regards  quality,  this  move  was  judicious  as  the  absence  of  these  components  today  does  not  prevent  the  design  of 
equipment  that  is  just  as  reliable  as  before.  However,  as  regards  long-term  availability,  it  means  that  manufacturers 
have  to  work  with  components  that  do  not  have  the  same  durability  as  those  that  were  formerly  intended  for  the 
long-cycle  industries; 

3)  the  considerable  developments  in  technology  that  meant  that,  for  the  first  time  in  1993-1994,  obsolescence  affected 
components  that  were: 

•  difficult  to  replace  (no  upward  compatibility), 

•  difficult  to  emulate  with  an  ASIC  (as  they  were  already  very  complex), 

•  and  had  an  impact  on  numerous  software  lines  (i.e.:  microprocessors). 

These  three  events  are  permanent,  not  to  mention  irreversible. 

The  professional  electronics  industry  could  therefore  no  longer  continue  to  treat  the  obsolescence  phenomenon  as  a 
minor  problem.  It  had  to  organise  itself  to  take  the  appropriate  steps  to  reduce  the  consequences  to  a  minimum  (as  no- 
one  has  yet  found  a  miracle  solution  to  end  the  phenomenon  of  obsolescence  or  completely  eliminate  its  consequences). 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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2.  The  analysis  of  the  situation  carried  out  at  Thomson- CSF 

2.1  Working  groups 

By  1995  it  was  clear  that  this  change  was  irreversible,  and  to  find  the  most  appropriate  response  to  it,  the  Thomson-CSF 
group  set  up  two  working  groups  with  representatives  from  all  of  the  units  affected,  for  various  reasons,  by  the  problem 
of  obsolescence. 

•  The  first  was  in  charge  of  analysing  the  short-term  responses  (mainly  curative)  to  the  problem  of  obsolescence. 

•  The  second  was  in  charge  of  analysing  the  preventive  measures  to  be  put  in  place  over  the  whole  life  cycle  of  a 
product  in  order  to  reduce  the  consequences  of  obsolescence  problems  to  a  minimum. 

These  groups  operated  during  1995  and  1996.  Their  recommendations  were  implemented  very  quickly  and  make  up  the 
anti-obsolescence  system  currently  used  within  Thomson-CSF.  These  groups  now  meet  two  to  four  times  a  year  to  re¬ 
analyse  the  situation  and  the  appropriateness  and  smooth  operation  of  the  system. 

The  existence  of  these  groups  allowed  for  plentiful  exchanges  between  the  units  represented,  both  on  the  problems 
encountered  and  on  the  best  practice  implemented  to  remedy  them.  Their  main  conclusions  are  set  out  below: 

2.2  The  problem  must  be  dealt  with  by  the  manufacturer 

The  first  element  that  appeared  in  the  working  groups  was  the  diversity  of  customers’  attitudes  to  the  obsolescence 
problem. 

The  Thomson-CSF  group  (and  therefore  the  units  represented  in  the  working  groups)  operates  on  three  main 
professional  electronics  markets: 

•  the  defence  sector, 

•  the  aerospace  sector, 

•  the  Business  to  Business  or  B  to  B  sector. 

This  position  allowed  it  to  note  that  customers  behave  in  radically  different  ways  when  faced  with  obsolescence  and 
that  this  behaviour  causes  equally  antagonistic  reactions  from  the  manufacturers. 

On  one  hand,  customers  in  the  civil  aviation  sector  (aircraft  manufacturers,  airlines  or  airports)  and  B  to  B  sector 
customers  feel  that  it  is  up  to  the  manufacturer  to  find  solutions  to  the  obsolescence  problem  and  wish  to  distance 
themselves  from  it  as  far  as  possible. 

On  the  other  hand,  in  the  defence  sector,  several  MoDs  in  large  countries  (particularly,  but  not  only,  the  US  DoD) 
wanted  to  find  solutions  to  the  obsolescence  problem  and  pass  them  on  to  their  manufacturers. 

This  second  attitude  is  a  sort  of  extension  of  the  old  situation  when  the  MoDs  (and  especially  the  DoD)  were  major 
suppliers  of  technology  in  the  field  of  components.  However,  in  the  new  situation,  it  inevitably  affects  costs 
optimization,  as  sharing  responsibilities  between  the  manufacturer  and  the  customer  does  not  facilitate  the  search  for  an 
overall  optimised  solution  to  the  obsolescence  problem.  Rather,  it  encourages  the  implementation  of  radical  but  costly 
solutions  (strategic  stocks,  financing  of  the  component  manufacturer,  setting  up  of  alternative  sources,  etc.)  when  very 
often  the  problem  could  be  solved  at  a  lower  cost  within  the  framework  of  a  more  general  approach  (as  several 
components  are  often  simultaneously  affected  by  obsolescence). 

This  attitude  leads  to  a  lack  of  competitiveness  for  the  manufacturer,  who  has  to  manage  two  conflicting  processes 
depending  on  which  market  it  is  dealing  with. 

Everything  points  towards  the  idea  that  this  specific  feature  of  the  domestic  defence  market  will  gradually  disappear. 
The  defence  market  has  already  admitted,  several  years  ago,  that  it  could  cover  90%  of  its  requirements  with 
components  designed  for  other  markets.  It  is  probable  that  sooner  or  later  it  will  also  decide  to  delegate  responsibility 
for  controlling  the  risks  linked  to  these  components  to  the  manufacturer,  as  other  professional  electronics  customers  do 
already. 

For  all  these  reasons,  it  was  apparent  that  the  Thomson-CSF  group  should  equip  itself  with  means  (tools  and  methods) 
to  allow  it  to  offer  all  its  customers,  including  those  in  the  defence  sector,  solutions  in  which  it  would  take  on  the 
obsolescence  control  itself.  Of  course,  this  does  not  exclude  dialogue  with  the  customer  to  inform  them  of  the  problems 
encountered  and  try  to  find  the  most  appropriate  responses  with  them.  Such  dialogue  is  even  strongly  encouraged  (see  § 
4.1).  Nor  does  it  exclude  working  differently  on  some  contracts,  with  customers  who  want  to  be  more  closely  involved 
in  the  search  for  solutions  to  obsolescence. 

There  is  now  a  wide  consensus  of  approval  for  this  process  in  France,  including  in  the  defence  sector;  the  French  MoD 
and  the  defence  manufacturers  are  on  the  point  of  entering  into  an  agreement  at  the  end  of  which  the  MoD  will  hand 
over  most  obsolescence  problem  control  to  the  manufacturers  and  even,  more  generally,  most  of  the  control  of  problems 
linked  to  components  (selection,  obsolescence,  quality,  reliability,  resistance  to  environment,  etc.). 

This  procedure  falls  within  the  same  logic  as  that  used  by  Thomson-CSF  and  the  French  MoD  in  the  area  of  component 
quality.  In  1988,  the  decision  was  taken  to  switch  to  commercial  and  industrial  components  to  replace  military 
components  (see  [2]).  This  began  with  radio  equipment  for  the  French  army.  Gradually,  this  strategy  spread  to  all  the 
equipment  produced  by  Thomson-CSF  in  all  areas  (aerospace,  defence,  B  to  B),  and  today  the  Thomson-CSF  group 
uses  very  few  military  range  components  or  QML  certified  components  on  new  designs.  The  group  itself  provides 
quality  assurance  using  a  very  strict  method  of  assessing  component  processes  (see  [3]).  This  yields  a  considerable 
saving  on  components  costs,  and  also  much  better  control  of  quality  and  reliability  in  severe  environments  (see  [4]). 

The  only  limit  that  must  be  placed  on  this  procedure  relates  to  components  with  specific  defence  uses.  These  are 
components  necessary  in  the  defence  area  (as  their  specific  performance  has  a  direct  impact  on  the  performance  of  the 
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defence  systems)  but  for  which  the  non-defence  market  is  too  small  to  ensure  the  financing  of  the  necessary  processes. 
A  typical  example  is  high  power  GaAs.  For  reasons  that  will  not  be  elaborated  on  here  (see  [4]),  it  is  often  difficult  for 
the  manufacturer  to  provide  this  financing.  Government  aid  may  be  necessary  to  provide  the  financing  and  prevent 
supply  shortages  that  would  cause  insurmountable  industrial  problems.  Again,  however,  the  procedure  must  be  to  limit 
these  processes  to  those  that  are  strictly  necessary,  so  that  this  procedure  is  the  exception  and  not  the  rule.  Moreover, 
this  is  what  is  recommended  in  Secretary  Perry’s  Memorandum  (see  [1]). 


2.3  The  procedure  must  cover  the  whole  life  cycle 

The  second  element  that  the  working  groups  agreed  on  unanimously  was  the  need  to  take  obsolescence  into  account  and 
to  seek  to  provide  the  best  responses  at  every  stage  of  the  life  cycle. 

Of  course,  the  first  question  that  comes  to  mind  in  a  discussion  about  obsolescence  is  to  find  out  which  solutions  are 
applied  to  it  (i.e.  once  the  problem  has  occurred). 

This  is  an  important  subject,  and  any  good  anti-obsolescence  system  should  provide  a  response  to  it.  We  will  therefore 
deal  with  this  subject  in  §3.1  and  4.3. 

However,  limiting  oneself  to  purely  curative  treatment,  once  the  problem  has  arisen,  is  certainly  not  the  best  way  to 
approach  obsolescence. 

In  fact,  in  addition  to  the  curative  approach  that  applies  to  the  phases  of  production  of  the  equipment  and  its  use  by  the 
customer  (including  logistic  support),  the  obsolescence  problem  must  be  analysed  constantly  at  each  stage  of  the  life 
cycle  with  the  aim  of  setting  out  the  best  solution  at  each  stage,  i.e.  the  solution  that  will  minimise  the  consequences  of 
obsolescence  in  future.  This  preventive  attitude  of  systematic  risk  anticipation  and  searching  for  the  best  solutions 
applies  to: 

•  the  production  and  customer  use  phase  (see  §3.2  and  4.3), 

•  the  development  phase,  particularly  for  component  selection  (see  §3.3), 

•  the  design  phase,  particularly  for  architecture  selection  (see  §3.4  and  4.2), 

•  and  even  the  pre-sales  phase,  as  the  establishment  of  sound  and  explicit  contractual  rules  between  the 
manufacturer  and  the  customer  is  such  a  vital  element  to  prevent  any  subsequent  misunderstanding  and  confusion 
(see  §4.1.2). 

2.4  The  variety  of  situations  and  appropriate  responses 

The  third  element  on  which  everybody  agreed  was  the  great  variety  of  situations  and  consequently  the  difficulty  of 
transposing  best  practice  as  it  is  from  one  unit  to  another  when  the  situations  are  too  different. 

As  a  rule,  for  each  situation,  the  selection  of  the  most  suitable  response  must  take  into  account: 

•  the  customer’s  needs.  The  range  of  applicable  solutions  would  therefore  be  very  small  if  the  customer  required  all 
its  equipment  to  be  strictly  identical.  The  range  would  be  larger  if  the  customer  were  satisfied  with  functional 
equivalence  (fit,  form,  function).  It  would  be  even  larger  if  the  customer  looked  favourably  on  progressive  updates 
to  the  equipment  in  order  to  benefit  from  technological  developments  (enhanced  performance  at  a  lower  cost); 

•  the  quantities  to  be  provided  and  the  interval  between  the  provision  of  these  quantities;  the  best  response  will  not 
be  the  same,  depending  on  whether  it  is: 

a  delivery  to  be  made  within  a  short  deadline  (<  2  years), 
a  large  quantity  to  be  delivered  within  a  long  deadline, 
a  small  quantity  to  be  delivered  within  a  long  deadline; 

•  the  “commonality”  between  products.  In  some  situations,  a  policy  of  designing  from  modules  common  to  several 
products  can  allow  for  better  optimised  responses  than  would  have  been  possible  if  each  product  had  been 
considered  in  isolation; 

•  etc. 

2.5  Use  of  common  tools  and  principles  for  obsolescence  control 

As  they  were  unable  to  define  best  practice  applicable  to  everyone  in  all  situations,  the  participants  of  the  two  working 
groups  rapidly  agreed  unanimously  on  the  benefit  of  pooling  their  experience  and  defining  a  set  of  common  principles 
and  setting  up  the  corresponding  tools. 

More  specifically,  they  came  up  with  the  following  analysis: 

1)  a  fundamental  approach  in  obsolescence  control  is  to  tackle  the  problem  in  terms  of  risk  control; 

2)  risk  control  can  be  broken  down  into  a  few  simple  principles  (list  of  questions  to  ask  oneself).  These  principles  can 
be  common  to  everyone,  even  if  the  responses  to  them  (best  practices)  vary  depending  on  the  individual  situation; 

3)  risk  control  requires  certain  tools  that  also  gain  by  being  common  to  everyone; 

4)  in  addition  to  the  principles  (theoretical),  a  collection  of  best  practice  can  be  very  useful  for  everyone  (benchmark 
type  approach),  even  if  it  is  not  always  easy  to  transpose  a  given  best  practice  from  one  situation  to  another. 

This  analysis  allowed  the  groups  to  design  a  system  that  was  common  to  all  of  the  units  in  the  group.  The  system  has 
now  been  in  operation  for  several  years,  and  will  be  described  in  this  paper. 
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However,  we  will  only  touch  briefly  on  the  best  practices  implemented  in  the  units,  as  they  are  often  linked  to  a  specific 
context  and  we  wish  to  focus  on  points  common  to  everybody  in  this  paper.  Other  papers  (particularly  [5],  which 
illustrates  the  procedure  recommended  in  §4.2.1),  give  a  clearer  idea  of  what  these  best  practices  might  be. 


2.6  The  common  obsolescence  control  system 

This  system  is  illustrated  in  figure  1 . 

As  we  have  just  seen,  it  is  made  up  of: 

•  a  (common)  tools  section,  supplemented  by  the  availability  of  expertise, 

•  a  (common)  methods  section,  supplemented  by  an  organisation  in  charge  of  coordination. 

It  covers  every  stage  of  the  life  cycle;  the  need  for  this  was  outlined  in  §2.3.  It  can  be  read  from  top  to  bottom,  in 
chronological  order  of  the  life  cycle,  or  in  the  opposite  direction,  in  increasing  order  of  maturity,  as  it  is  true  that  the 
most  mature  responses  are  those  that  anticipate  the  problem  as  far  upstream  as  possible. 

We  will  now  describe  it  in  more  detail.  We  will  begin  with  the  tools  aspect,  which  is  easier  to  approach  first  as  it  gives 
concrete  responses  to  specific  problems.  The  tool  aspect  will  be  covered  in  chapter  3.  We  will  then  deal  with  the 
methods  aspect,  which  is  in  essence  more  abstract,  in  chapter  4. 
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Figure  1  :  Common  obsolescence  control  system 
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3.  Common  obsolescence  control  tools  in  use  in  Thomson-CSF 

Sticking  to  our  philosophy  of  giving  first  a  description  of  the  precise  responses  given  to  the  most  concrete  problems,  we 
will  describe  the  tools  part  of  the  common  system  in  an  “upstream  order”  through  the  life  cycle  of  equipment.  This  will 
enable  us  to  describe  the  means  put  in  place  to  find  solutions  when  problems  are  urgent,  generally  during  the  phases  of 
production  or  customer  use  of  the  equipment.  We  will  then  examine  what  can  be  done  in  a  more  preventive  (and  more 
mature!)  way  by  trying  to  anticipate  problems,  firstly  during  the  phases  of  production  or  customer  use,  and  then  -  better 
still  -  during  the  upstream  phases  of  the  life  cycle,  design  and  development. 


3.1  The  tools  and  expertise  for  curative  treatment 

The  tools  and  expertise  for  curative  treatment  meet  two  aims: 

1)  to  allow  the  units  to  be  informed  of  problems  in  due  time, 

2)  to  allow  the  units  to  take  corrective  action  in  due  time. 

3.1.1  Being  informed  of  problems  in  due  time 

Although  it  may  initially  seem  surprising,  the  first  obstacle  to  overcome  to  set  up  an  effective  curative  treatment  process 
for  obsolescence  is  having  the  necessary  information  in  due  time. 

From  the  component  suppliers’  point  of  view,  the  main  characteristic  of  the  professional  electronics  industries  is  that 
they  give  small  orders  spread  over  long  periods.  The  suppliers  do  not  therefore  always  automatically  think  of  informing 
a  “small  customer”  about  all  obsolescence,  in  particular  when  it  occurs  in  components  that  the  “small  customer”  hasn’t 
ordered  for  months  (sometimes  years),  or  has  never  ordered  before.  Using  sub-contractors  for  production  only 
aggravates  the  problem  as  it  creates  yet  another  link  in  the  information  chain,  with  all  the  risks  involved. 

During  1993  to  1995,  each  Thomson-CSF  unit  had  gradually  set  up  its  own  obsolescence  information  gathering  and 
processing  department.  However,  this  was  costly  and  inefficient  in  terms  of  cover. 
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The  decision  was  therefore  taken  in  1995  to  give  a  support  unit,  TTM  (Thomson-CSF  Technologies  and  Methods), 
responsibility  for  collecting  and  processing  all  the  obsolescence  information  and  distributing  it  to  all  of  the  units  in  the 
group. 

The  initial  principle  was  to  ask  every  purchaser  who  was  aware  of  an  obsolescence  problem  to  inform  TTM,  which 
would  then  immediately  pass  the  information  on  to  all  of  the  units.  In  reality  today,  the  information  gathered  by  TTM 
comes  mainly  from  relationships  established  with  manufacturers  and  a  systematic  analysis  of  their  web  sites  and  of 
independent  specialist  obsolescence  web  sites.  The  purchasers  now  only  provide  additional  information  that,  above  all, 
highlights  any  deficiencies  in  the  cover  or  reactivity  of  the  system. 

As  shown  in  figure  2,  the  system  actually  goes  well  beyond  simply  distributing  the  information  received: 

First,  the  information  gathered  is  processed.  This  work  gives  considerable  added  value  in  relation  to  the  raw 
information,  which  is  often: 

redundant  (several  suppliers  announce  the  same  measures), 

inconsistent  (some  obsolescence  is  a  stoppage  at  the  distributor,  but  the  products  still  exist  elsewhere), 

non-specific  (a  supplier  announces  that  a  family  is  no  longer  produced,  without  specifying  an  exact  list  of  the 
parts  affected); 

Then,  the  components  in  question  are  matched  with  the  Thomson-CSF  component  information  system,  which  allows 
the  units  to  identify  them  easily  in  their  item  databases.  This  also  gives  an  initial  list  of  potential  replacement 
components. 

When  the  file  created  in  this  way  is  distributed  (once  a  fortnight),  the  units  are  asked  in  return  to  indicate  which 
components  affect  them. 

Thanks  to  this  return  of  information,  2  additional  services  can  be  provided: 

firstly,  an  additional  equivalents  search  (complete  or  approximate)  is  systematically  initiated  and  the 
information  obtained  is  systematically  checked:  when  a  component  goes  out  of  production,  it  is  often  the 
market  that  has  disappeared  and  it  is  therefore  useful  to  check  that  the  equivalents  have  not  also  gone  out  of 
production; 

secondly,  each  unit  also  receives  a  list  of  the  other  units  with  the  same  problem,  which  is  very  useful  for 
helping  each  other  or  looking  for  solutions  together  (stock,  after  market,  substitute  ASIC  or  PLD,  etc.); 

Finally,  the  information  is  archived  in  the  Thomson-CSF  Component  Information  System  (TCIS)  so  that  it  can  be  found 
again  later. 

Today,  this  system  is  fully  operational  and  every  unit  receives  a  file  once  a  fortnight  containing  all  the  obsolescence 
detected  over  the  last  two  weeks.  The  widely  held  opinion  is  that  the  coverage  is  very  good. 

Obsolescence  warnings  were  given  in  this  way  for  20,000  components  in  1999.  The  responses  provided  in  return  by  the 
units  show  that,  statistically,  10%  of  these  components  (2,000  per  year)  have  an  impact  on  at  least  one  unit  in  the  group. 
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Figure  2  :  Obsoiescence  warning  system 


3.1.2  Taking  corrective  action  in  due  time 

The  second  obstacle  to  overcome  when  setting  up  an  effective  curative  obsolescence  treatment  process  is  knowing  how 
to  take  corrective  action  in  due  time. 
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Unlike  the  previous  obstacle  (gathering  information),  for  which  a  central  service  alone  can  give  100%  of  the  solution, 
decision  making  is  a  process  that  requires  a  great  deal  of  internal  organisation  within  each  unit  (we  will  deal  with  this 
subject  in  §4.3)  and  which  can  be  made  much  easier  by  anticipation  (we  will  deal  with  this  subject  in  §3.2,  3.3  and  3.4). 
However,  a  central  service  can  still  help  significantly  in  finding  solutions. 

The  Thomson-CSF  group  therefore  decided  to  create  an  “Obsolescence  Task  Force”  (TFO)  with  the  task  of  helping  the 
units  find  solutions. 

In  practice,  the  solutions  can  be  very  varied  in  nature: 

1 )  searching  for  a  strictly  equivalent  component, 

2)  searching  for  a  more  or  less  equivalent  component, 

3)  creating  a  reserve  stock, 

4)  buying  stock  available  on  the  market, 

5)  sharing  stocks  between  units, 

6)  negotiation  with  the  supplier, 

7)  calling  on  after  market  companies, 

8)  producing  a  substitute  component  (ASIC  or  FPGA), 

9)  partial  or  total  redesign  of  the  card, 

10)  etc. 

As  we  can  see,  some  of  these  are  purchasing  solutions  and  others  are  technical  solutions  (or  require  technological 
expertise).  They  must  all  be  decided  on  urgently.  Finally,  sharing  between  units  is  often  an  advantage,  whether  for 
finding  solutions  or  implementing  them,  as  knowledge  is  pooled,  costs  are  shared,  the  units  have  greater  weight  in 
negotiations,  etc. 

The  Obsolescence  Task  Force  (TFO)  is  therefore  made  up  of: 

•  a  network  of  purchasing  experts, 

•  a  network  of  technical/technological  experts, 

•  and  a  coordinator. 

The  coordinator  is  the  single  interface  for  all  of  the  units  whenever  they  need  help  regarding  obsolescence.  They  can 
contact  him  at  any  time  by  email,  fax  or  telephone.  They  can  also  visit  his  web  site  where  they  can  find  advice, 
warnings  and  in  particular,  the  accumulation  of  answers  to  questions  in  an  FAQ  (Frequently  Asked  Questions)  section. 
In  many  cases,  due  to  his  experience  with  such  problems,  the  coordinator  can  answer  the  questions  he  is  asked  straight 
away.  However,  for  new  subjects  he  may  consult  one  of  the  networks  of  experts.  In  addition,  the  coordinator, 
sometimes  with  the  help  of  the  networks,  has  the  task  of  coordinating  the  research  and  implementation  of  solutions 
common  to  several  units  when  it  appears  that  a  common  solution  is  preferable  to  several  separate  solutions. 

The  purchasing  network  is  made  up  of  component  buyers  from  the  different  units,  who  therefore  have  wide  experience 
of  concrete  problems.  They  are  both  customers  of  the  TFO  when  they  are  looking  for  a  solution,  and  solution  providers 
when  another  unit  has  asked  a  question  via  the  TFO  and  they  have  the  answer. 

The  technical  network  is  made  up  of  technological  experts  with  in-depth  knowledge  of  the  components  field.  Most  of 
these  experts  are  in  TTM,  which  has,  amongst  others,  the  task  of  evaluating  the  components  and  components  processes 
for  the  whole  of  the  Thomson-CSF  group.  These  experts  carry  out  systematic  studies  in  the  area  of  obsolescence  on 
subjects  such  as: 

•  the  interchangeability  rules  between  technologies  and  the  precautions  to  take, 

•  the  extension  of  temperature  ranges,  upgrading,  derating, 

•  the  assessment  through  technical  audits  of  the  quality  and  reliability  of  the  products  offered  by  after  market 
manufacturers, 

•  the  methodological  rules  to  follow  to  transfer  an  ASIC  or  FPGA  design  to  a  more  recent  generation, 

•  etc. 

The  units  can  consult  the  technical  experts  at  any  time  on  obsolescence  problems,  either  directly  or  via  the  TFO 
coordinator.  The  results  of  their  studies  are  made  available  to  everyone  on  the  TFO  web  site. 


3.2  The  tools  and  expertise  to  anticipate  in  the  production  or  customer  use  phases 

In  §3.1.1  and  3.1.2,  we  mentioned  what  should  be  done  every  time  an  obsolescence  warning  arrived.  Obviously,  the 
problem  of  controlling  the  obsolescence  risk  cannot  be  resolved  optimally  using  curative  methods  alone. 

In  addition  to  these  methods,  which  remain  vital,  it  is  important  to  anticipate. 

In  §3.3  and  3.4  and  later  in  chapter  4,  we  will  discuss  anticipation  during  the  equipment  design  and  development 
phases.  In  this  paragraph,  we  will  start  by  looking  at  what  kind  of  anticipation  can  be  done  during  the  downstream 
production  and  customer  use  phases,  that  is,  after  the  equipment  is  developed. 

When  obsolescence  affects  a  piece  of  equipment,  the  very  first  reflex  must  be  to  ask  whether  further  obsolescence  is 
about  to  occur.  Nothing  proves  that  the  solution  (stock,  upgrade,  redesign,  etc.)  that  seems  best  to  handle  obsolescence 
taken  in  isolation  will  remain  the  best  solution  if  the  fact  that  further  obsolescence  is  about  to  occur  is  taken  into 
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account  in  the  economic  analysis.  For  example,  how  much  stock  has  been  scrapped  because  soon  afterwards,  further 
obsolescence  has  meant  that  a  module  has  to  be  completely  reworked? 

The  difficulty  is  that  if  one  waits  for  obsolescence  to  occur  to  carry  out  this  analysis,  it  is  often  too  late,  as  time  is  short 
and  urgent  action  is  required. 

Again,  the  mature  attitude  is  to  anticipate.  The  part  list  for  every  piece  of  equipment  must  be  reviewed  regularly  (every 
12  months)  and  the  following  action  taken; 

•  analyse  the  predicted  end  of  life  date  of  each  component  in  the  equipment, 

•  update  the  sales  projections  for  the  equipment, 

•  depending  on  these  two  analyses,  update  the  projected  redesign  dates  and  the  course  of  action  to  be  taken  until  the 
next  date. 

To  support  the  units  in  this  procedure,  the  Thomson-CSF  group  decided  to  provide  them  with  a  tool  and  expertise;  the 
tool,  known  as  Technolife,  is  a  database  maintained  and  distributed  by  TTM  that  contains  predicted  end  of  life  dates  for 
a  large  number  of  components. 

In  addition,  for  components  that  are  not  in  the  database,  the  units  have  access  to  the  component  experts  in  TTM  and 
other  units  (via  the  TFO).  Furthermore,  the  answers  given  are  amassed  in  the  Technolife  database  and  then  updated 
every  year,  which  allows  Technolife  to  give  excellent  coverage  of  the  components  used  by  the  Thomson-CSF  units. 


3.3  The  tools  and  expertise  to  anticipate  in  the  development  phase 

In  §3.1  and  3.2  we  mentioned  what  should  be  done  to  control  the  obsolescence  risk  during  the  production  and  use 
phases,  that  is,  on  equipment  that  has  already  been  designed. 

Taking  the  obsolescence  problem  into  account  on  equipment  in  the  upstream  phases  of  the  life  cycle  opens  up  many 
other  levels  of  freedom. 

During  the  development  phase,  and  particularly  when  the  list  of  components  is  selected,  the  level  of  freedom  consists  of 
choosing  components  with  the  best  long-term  availability  prospects  possible. 

Unfortunately,  although  it  is  easy  to  set  out  this  aim,  it  is  costly  to  implement.  Indeed,  forming  an  opinion  on  the  long¬ 
term  availability  prospects  of  a  component  requires  market  research,  which  has  a  cost.  (It  goes  without  saying  that  the 
manufacturer’s  sales  pitch  is  generally  not  enough  to  gain  an  objective  idea  of  the  long-term  availability  prospects  of 
the  components  in  their  catalogue!) 

The  route  taken  at  Thomson-CSF  to  meet  this  aim  at  a  reasonable  cost  was  to  try  to  cut  the  selection  of  components  for 
all  the  units  down  to  a  very  small  number  (see  [4]).  Initially  (1994)  when  the  decision  was  taken,  the  task  seemed 
immense  and  almost  insurmountable,  as  the  areas  in  which  the  units  worked  seemed  so  diverse  and  their  needs  seemed 
so  divergent.  However,  gradually,  due  to  a  highly  reactive  process  in  which  each  unit’s  needs,  including  for  the  most 
recent  components,  were  systematically  analysed  and  due  to  a  better  collective  awareness  of  the  risks  involved  in 
making  inopportune  choices,  all  of  the  units  were  able  to  agree  on  common  choices  for  products  being 
designed/developed. 

Today,  a  very  small  set  of  components  (2,500  parts,  of  which  500  are  active)  known  as  the  Thomson-CSF  components 
preferred  parts  list  (PPL),  allows  most  of  the  units  in  the  group  to  cover  approximately  80%  of  their  needs. 

From  the  point  of  view  of  obsolescence  control,  the  use  of  the  Thomson-CSF  PPL  is  a  very  effective  method,  as  it 
allows  the  following  activities  to  be  carried  out  for  a  cost  shared  between  all  of  the  units  in  the  group; 

1)  market  research  so  that  the  component  with  the  best  long-term  availability  prospects  can  be  chosen,  function  by 
function. 

2)  regular  updates  of  this  market  research  in  order  to  anticipate  possible  problems  well  before  the  official  withdrawal 
announcements. 

In  reality,  the  benefits  of  the  Thomson-CSF  components  PPL  goes  far  beyond  questions  relating  to  obsolescence; 

•  regarding  quality/resistance  to  environment,  it  allows  for  a  similar  procedure,  i.e.  in-depth  analysis  of  the  quality  of 
the  selected  processes  and  monitoring  changes  to  this  quality  over  time.  Remember  that  Thomson-CSF  has 
implemented  its  own  quality  assurance  policy  to  select  the  civil  component  processes  (commercial  or  extended 
ranges)  that  offer  sufficient  guarantees  to  be  used  in  extreme  environments,  with  all  the  reliability  necessary  (see 
§2.2); 

•  regarding  purchasing,  it  allows  negotiations  to  be  focused  on  a  small  number  of  components  and  suppliers,  meaning 
that  better  conditions  can  be  obtained  (prices,  deadlines,  service); 

•  regarding  the  models  necessary  for  CAD  tools,  the  number  of  components  to  be  modelled  can  be  significantly 
reduced,  thus  reducing  production  costs; 

•  regarding  exchanges  of  experience  (technical,  quality,  purchasing),  the  fact  that  all  of  the  units  use  the  same 
components  greatly  encourages  information  exchanges. 

In  addition  to  the  PPL  tool,  the  units  can  also  systematically  turn  to  the  TTM  experts  for  part  list  reviews; 

•  for  the  unit,  it  is  a  way  of  understanding  the  various  options  possible  and  the  associated  risks, 

•  for  TTM,  it  is  an  additional  means  of  updating  the  PPL  through  analysing  any  inadequacies  it  may  have  on  a 
specific  project. 
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3.4  The  tools  and  expertise  to  anticipate  in  the  design  phase 

Approaching  the  obsolescence  problem  even  further  upstream,  i.e.  during  the  design  phase  of  a  piece  of  equipment, 
gives  the  advantage  of  a  further  level  of  freedom  -  designing  an  architecture  that  can  better  withstand  component 
obsolescence. 

We  will  not  expand  on  this  point,  which  is  dealt  with  in  §4.2.1.  However,  we  will  look  ahead  to  the  recommendation 
made  in  the  conclusion  to  that  paragraph;  the  evolution  of  the  architecture  over  the  whole  life  cycle  must  be  analysed 
from  the  start  of  the  project. 

Unfortunately,  technology  evolves  very  rapidly  (see  the  consequences  of  Moore’s  law  in  §4.2.1).  It  is  therefore  almost 
impossible  to  successfully  analyse  a  life  cycle  if  there  is  no  tool  that  allows  an  overview  of  this  technological  evolution. 

Such  a  tool  has  been  set  up  within  the  Thomson-CSF  group.  This  is  a  knowledge  base  known  as  Technoprice.  Based  on 
Moore’s  law  and  the  expertise  of  the  best  components  specialists  in  the  group,  it  contains  the  forecasted  evolution  for 
the  next  ten  years  in  the  performance,  price  and  functions  of  the  components  useful  to  the  different  units  in  the  group.  It 
is  distributed  to  all  of  the  units  in  the  group. 

Using  the  information  it  contains,  it  is  possible  to: 

•  gain  a  realistic  idea  of  the  performance  upgrades  and/or  price  decreases  of  a  given  architecture, 

•  gain  a  realistic  idea  of  the  performance  and  price  of  competing  equipment  in  5  or  10  years. 

It  is  therefore  a  tool  to  optimise  the  choice  of  architecture  in  order  to  make  the  equipment  competitive  for  as  long  as 
possible. 

4.  Methodological  principles  for  obsolescence  control  in  use  in  Thomson-CSF 

In  chapter  3,  we  listed  the  tools  and  expertise  that  the  Thomson-CSF  group  provides  all  of  the  units  for  the  most 
effective  obsolescence  control  possible. 

Of  course,  tools  and  expertise  (that  is,  in  both  cases,  information),  are  not  sufficient  to  deal  effectively  with 
obsolescence.  In  addition,  and  above  all,  organisation  and  methods  are  required. 

These  must  be  put  in  place  in  each  unit. 

As  we  pointed  out  in  §2.2,  the  organisation  and  methods  can  vary  considerably  from  one  unit  to  another,  in  that  they 
must  be  suited  both  to  the  rest  of  the  unit’s  organisation  and  in  particular  to  the  type  of  market  and  type  of  customer  the 
unit  targets. 

However,  this  does  not  mean  that  there  is  nothing  to  pool  within  a  group  which,  like  Thomson-CSF,  operates  with  a 
great  variety  of  customers  and  markets.  Hence,  the  working  groups  mentioned  in  §2.1  made  the  following  analysis: 

Firstly,  simply  sharing  organisations  and  methods  created  by  other  units  can  be  very  useful  as  it  is  intellectually 
stimulating.  The  Obsolescence  Task  Force  therefore  created  a  “best  practices’’  section  on  its  web  site.  This  offers  a  way 
for  units  to  benchmark  themselves  against  others.  Moreover,  the  meetings  of  the  obsolescence  representatives  organised 
by  the  TFO  enable  these  best  practice  exchanges  to  be  taken  further  through  direct,  informal  contact. 

However,  it  seemed  possible  to  go  further  than  simply  exchanging  best  practices. 

When  the  different  best  practices  are  analysed,  it  can  be  seen  that  the  basic  attitude  behind  them  is  to  view  obsolescence 
as  a  risk  and  look  for  remedies  in  a  risk  control  type  procedure. 

This  obsolescence  risk  control  itself  involves  two  rules  of  conduct: 

1)  upstream  of  the  life  cycle  (design  and  development  phases),  knowing  how  to  anticipate  the  risk  in  order  to  make  the 
choices  that  will  minimise  the  consequences  when  the  risk  becomes  reality, 

2)  downstream  of  the  life  cycle  (production  and  use  phases),  knowing  how  to  be  reactive,  i.e.  being  able  to  take  the 
decisions  that  enable  the  consequences  to  be  minimised  when  the  risk  becomes  reality. 

The  choices  to  be  made  upstream  of  the  life  cycle  that  have  an  impact  on  obsolescence  control  can  be  broken  down  into; 

•  management  choices  (with  the  customer  playing  a  significant  role), 

•  technical  choices. 

Downstream,  reactivity  is  above  all  a  matter  of  organisation. 

We  will  therefore  look  at  these  three  points  in  turn  in  the  following  three  paragraphs. 

4.1  Controlling  the  obsolescence  risk  upstream:  the  role  of  management  and  the  customer 

4.1.1  Thinking  through  the  life  cycle 

As  by  its  very  essence,  obsolescence  has  delaying  effects  (even  though  the  acceleration  of  replacement  of  components 
makes  these  effects  appear  earlier  and  earlier  in  the  programmes),  the  consequences  and,  most  importantly,  the  cost  of 
obsolescence  can  only  be  minimised  if  one  thinks  through  the  whole  life  cycle,  right  from  the  start  of  the  programme,  in 
an  LCC  (Life  Cycle  Cost)  approach.  It  is  clear  (we  will  return  to  this  point  in  the  following  paragraph)  that  choosing 
architecture  that  allows  for  a  minimum  cost  for  the  first  years  of  the  life  of  a  project  does  not  necessarily  mean  that  it 
will  allow  for  a  minimum  cost  over  the  whole  life  cycle.  To  go  further,  not  only  the  acquisition  cost  of  the  equipment 
should  be  taken  into  account,  but  more  generally  the  cost  of  ownership  as  seen  by  the  customer  and  including  the 
impact  of  the  performance  aspect.  However,  this  does  not  alter  the  conclusion,  which  is  that  to  minimise  the  LCC,  the 
whole  of  the  life  cycle  must  be  analysed  right  from  the  start  of  the  programme. 
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4.1.2  Clarify  the  rules  with  the  customer 

It  is  clearly  the  responsibility  of  the  programme  manager  and/or  their  customer  to  impose  this  type  of  life  cycle 
reasoning  we  have  just  discussed.  This  might  seem  obvious,  and  so  it  is  when  the  manufacturer  is  committed  to 
supplying  given  quantities  on  given  dates  at  a  given  price.  It  also  is  when  the  manufacturer  is  committed  to  keeping  a 
product  in  its  catalogue  for  a  given  period  at  a  given  price.  In  the  second  case,  when  the  customer  has  not  made  a  clear 
commitment  on  quantities,  the  manufacturer  will  make  projections  and  base  its  strategy  on  these  projections. 

However,  the  rules  are  not  always  this  explicit,  particularly  for  contracts  made  with  governments  (and  not  only  in  the 
defence  sector).  For  various  reasons,  the  customer  may  have  problems  making  a  long-term  commitment  on  order 
volumes  and  a  specific  schedule.  When  the  customer  is  a  government,  the  strong  impact  of  politics  can  make  volume 
and  schedule  projections  very  difficult  for  the  manufacturer.  Sometimes  (and  again,  often  for  tactical  or  even  political 
reasons),  the  customer  might  prefer  an  offer  in  which  the  initial  acquisition  cost  is  lower  (as  this  will  allow  it  to  launch 
the  programme)  to  an  offer  in  which  the  overall  cost  of  possession  is  optimised. 

In  all  cases,  and  even  if  it  is  not  pushed  by  its  customer,  the  manufacturer’s  course  of  action  must  be  to  analyse  the 
complete  life  cycle  of  the  equipment,  draw  up  a  solution  that  minimises  the  LCC  and  offer  it,  even  if  only  as  an  option, 
to  the  customer.  The  customer  is  then  free  to  give  another  criterion  for  optimisation  if  this  criterion  meets  its  own 
constraints  better.  At  least  the  ambiguity  will  be  removed. 

4.1.3  Budgeting 

Once  the  principles  of  optimisation  over  the  whole  life  cycle  have  been  accepted  by  both  the  manufacturer  and  the 
customer,  the  manufacturer  must  evaluate  the  cost  of  obsolescence  control  and  put  in  place  the  corresponding  budgets 
(which,  in  certain  situations,  requires  the  customer’s  agreement  again). 

Again,  this  is  obvious,  but  in  1995-1996,  when  the  analysis  was  carried  out,  many  contracts  were  faced  with  the 
obsolescence  control  problem  without  having  budgeted  for  it.  This  often  prevented  the  correct  decisions  being  made  in 
due  time.  The  working  group  therefore  felt  that  it  was  appropriate  to  set  out  this  rule  explicitly. 

4.2  Controlling  the  obsolescence  risk  upstream:  the  importance  of  technical  choices 
4.2.1  Incremental  design 

When  the  decision  is  taken  to  optimise  the  LCC  for  a  product,  the  immediate  consequence  is  that  the  technical 
managers  have  to  envisage  the  architecture  of  the  product  and  its  development  over  the  whole  life  cycle  in  order  to 
produce  and  optimise  cost  estimates.  An  analysis  of  Moore’s  law  helps  understanding  the  benefit  of  carrying  out  this 
exercise  (and,  incidentally,  proves  how  difficult  it  is).  This  law  states  that  on  average  the  geometry  of  semiconductors 
decreases  by  15%  per  year.  This  has  proved  true  over  the  last  30  years  and  should  continue  to  be  so  for  at  least  the  next 
ten.  The  consequence  of  this  (see  figure  3)  is  that  chip  performance  doubles  every  15  months,  or  increases  tenfold  every 
4  years,  or  increases  by  a  factor  of  1,000  every  12  years.  Unless  it  is  prices  that,  for  constant  performance,  drop  by  the 
same  proportions,  or  any  other  intermediate  solution. 


Figure  3:  Moore’s  law  and  its  consequences 


This  explains  why  the  consumer  industries  are  constantly  bringing  out  new  models;  which  child  would  buy  a  play 
station  designed  15  months  ago  when  a  competitor  has  just  brought  out  a  new  version  that’s  twice  as  powerful?  As  a 
result,  the  components  come  onto  the  market  and  disappear  one  after  the  other  at  the  same  speed,  fortunately  with  a  lag 
on  withdrawals  due  to  production  cycles. 

The  difficulty  for  the  professional  electronics  industries  is  that  the  quantities  sold  are  much  lower  and  therefore  the 
design  and  industrial  development  costs  are  proportionately  a  much  greater  factor  in  the  production  cost.  Moreover,  and 
for  reasons  of  equipment  homogeneity,  the  customer  will  want  to  be  able  to  buy  the  same  product  for  several  years,  or 
at  least  a  product  with  an  identical  external  interface  -  and  yet  still  benefit  from  the  price  reductions  due  to 
technological  developments. 

In  professional  electronics,  the  manufacturer  must  therefore  do  the  following  simultaneously: 

1)  somehow  resolve  obsolescence  problems  so  that  it  can  continue  production; 

2)  constantly  improve  the  competitiveness  of  its  products  (price  and  performance)  so  that  it  can  continue  to  sell; 

3)  minimise  redesign/re-industrial  development  costs,  which  are  very  high  overall. 
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The  solution  proposed  within  the  Thomson-CSF  group  to  reconcile  these  three  aims  is  to  use  an  incremental  design 
procedure. 

This  procedure  can  broadly  be  compared  with  the  well-known  procedure  in  the  US  known  as  RASSP  (see  [6]).  We  will 
therefore  limit  ourselves  to  a  general  description  of  it. 

The  aim  of  incremental  design  is  to  define  a  procedure  to  optimise  the  LCC.  This  procedure  applies  to  the  whole  life 
cycle.  The  first  stage  (and  probably  the  most  important  and  most  difficult  stage)  consists  of  analysing  the  LCC  from  the 
start  of  the  project  in  order  to  optimise  it.  This  involves  making  projections  far  into  the  future  in  order  to  anticipate 
changes  in  architecture  and  draw  up  estimates  of  the  cumulative  recurrent  and  non-recurrent  costs  over  the  whole  life 
cycle  of  the  equipment.  In  most  cases,  this  LCC  optimisation  process  leads  to  breaking  the  equipment  down  into 
modules  and  a  strategy  of  gradually  improving  the  modules  one  by  one  over  the  years.  It  also  leads  to  a  clear  definition 
(stabilisation)  of  the  portability  interfaces  between  modules,  so  that  one  module  can  be  upgraded  without  affecting  the 
operation  of  the  other  modules.  (It  must  be  noted  that  these  can  be  hardware  or  software  portability  interfaces). 

The  idea  is  to  take  inspiration  from  the  automotive  industry.  For  years,  manufacturers  offer  a  product  with  the  same 
name  and  more  or  less  the  same  external  interface.  Every  year,  a  new  model  comes  out  with  an  “extra  feature” 
(increased  performance,  improved  comfort,  lower  price,  etc.)  designed  to  make  it  more  attractive  to  customers. 
Flowever,  the  whole  car  has  not  been  redesigned  from  scratch.  Inside,  everything  is  designed  in  modules,  and  every  year 
one  or  two  modules  change  and  the  rest  remains  identical. 

This  kind  of  process  is  the  opposite  of  the  process  that  used  to  be  conventional  in  professional  electronics,  whereby  a 
piece  of  equipment  was  designed  to  be  reproduced  identically  for  years.  This  often  leads  to  specifying  performance  at 
the  very  limit  of  what  was  feasible  at  the  time,  and  therefore  to  taking  risks,  increasing  costs,  causing  delays,  etc.  This 
conventional  approach  is  no  longer  conceivable  today.  After  a  few  years,  for  one  thing  the  original  components  have 
been  withdrawn,  there  are  no  equivalents  available  and  no-one  knows  how  to  produce  the  equipment  any  more.  For 
another  thing,  competitors  have  placed  a  more  recent  and  therefore  higher  performance,  cheaper  product  on  the  market, 
and  it  is  impossible  to  sell  the  old  product.  Moreover,  the  economic  pressure  on  budgets  means  that  the  next  generation 
cannot  be  redesigned  from  scratch. 

The  advantage  of  incremental  design  is  that,  due  to  anticipation  and  modular  design,  gradual  upgrades  to  the  equipment 
can  be  scheduled,  which  allows  the  manufacturer  to  avoid  high  and  recurring  redesign  costs.  From  the  customer’s  point 
of  view,  this  approach  allows  them  to  benefit  from  the  advantages  of  technology  progresses:  enhanced  performance 
and/or  reduced  costs. 

Figure  4  summarises  this  approach  and  outlines  the  rules  set  out  within  Thomson-CSF  for  its  implementation. 
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Figure  4:  The  incremental  design  approach 


Of  course,  one  can  object  that  incremental  design  does  not  apply  to  all  situations. 

Firstly,  it  requires  the  customer’s  cooperation.  The  customer  has  to  accept  that  the  equipment  supplied  throughout  the 
whole  life  cycle  will  be  compatible  (it  will  have  the  same  external  interface),  but  not  necessarily  100%  identical  inside. 
It  must  also  agree  to  not  demand  extremely  high  levels  of  performance  immediately,  as  this  often  makes  it  impossible  to 
break  the  equipment  down  into  modules.  As  a  matter  of  fact,  it  is  much  better  to  build  in  safety  margins  regarding 
technological  limits  and  break  the  equipment  down  into  modules  that  will  allow  for  the  product  to  be  improved  over  its 
whole  life  cycle:  as  performance  is  doubled  every  15  months,  it  is  better  to  implement  a  less  than  optimum  solution  very 
quickly  rather  than  introduce  delay  just  to  gain  20%. 

Secondly,  the  incremental  design  approach  must  be  modulated/adapted  for  large  production  runs  when  recurrent  costs 
are  much  greater  than  non-recurrent  costs. 


14-11 


Thirdly,  it  may  be  hardly  applicable  when  the  product  will  have  a  very  short  life  cycle. 

However,  even  in  this  last  case  it  (or  more  precisely,  a  variant  of  it)  may  be  worthwhile  if  it  can  be  applied 
simultaneously  to  several  products;  one  interesting  approach  used  by  Thomson-CSF  units  with  several  products  with 
similarities  is  to  design  common  modules  for  the  products  and  implement  an  incremental  design  policy  for  these 
modules,  which  often  have  a  longer  life  cycle  than  the  products. 

In  all  cases,  the  rule  is  to  analyse  the  evolution  of  the  architecture  over  the  whole  life  cycle  from  the  start  of  the  project. 
Whether  it  will  be  beneficial  to  use  incremental  design  or  a  variant  of  it  will  become  clear  from  the  analysis. 
Technoprice  (cf.  §3.4)  is  the  tool  used  at  Thomson-CSF  to  provide  the  elements  required  for  this  analysis. 

4.2.2  The  COCISPER  methodology 

The  almost  complete  withdrawal  of  MSI  components  today  and  the  increasing  scarcity  of  standard  VLSIs  in  favour  of 
components  that  provide  increasingly  specialised  functions  (ASSP  or  even  ASIC)  mean  that  the  professional  electronics 
industry  has  to  turn  increasingly  to  specialised  components  (ASIC  or,  if  quantities  do  not  allow  for  this,  FPGA). 

For  the  professional  electronics  industry,  items  such  as  FPGAs  are  an  excellent  response  to  obsolescence  problems.  As 
he  possesses  the  VHDL  description,  the  manufacturer  has  control  on  the  function  performed  by  the  component  and  is  in 
a  better  position  to  solve  obsolescence  problems.  Furthermore,  FPGAs  also  provide  a  solution  to  the  problem  of 
performance  upgrades  mentioned  in  the  previous  paragraph. 

However,  they  are  subject  to  obsolescence  themselves. 

In  the  event  of  obsolescence,  it  is  important  that  the  manufacturer  knows  how  to  “carry”  the  function  performed  by  the 
obsolete  component  over  to  a  more  recent  component  at  a  low  cost  (often  with  the  possibility  of  grouping  functions 
together).  To  ensure  this  kind  of  control,  French  manufacturers  have  defined  a  methodology  for  mastering  ASICs  and 
FPGAs  lifecycle  with  the  help  of  the  DGA.  A  description  of  this  can  be  found  in  another  paper  at  this  conference  (see 

[7]). 

4.2.3  The  use  of  a  components  preferred  parts  list 

We  will  not  go  over  this  subject  again,  as  it  was  amply  covered  in  §3.3.  However,  it  is  obvious  that  using  components 
carefully  selected  for  their  long-term  availability  prospects  and  then  carefully  monitored  for  obsolescence  is  a  major 
factor  in  minimising  the  obsolescence  risk. 


4.3  Controlling  the  obsolescence  risk  downstream:  the  role  of  organisation 
4.3.1  Organisational  reactivity 

In  the  downstream  phases  (production  and  use  phases),  that  is,  once  the  equipment  has  been  designed  and  developed, 
the  main  skill  a  manufacturer  needs  to  control  obsolescence  is  reactivity,  i.e.  the  ability  to  make  the  right  decision  in  due 
time  (often  very  quickly)  when  a  problem  arises.  It  must  be  noted  that,  in  some  serious  situations  when  the 
manufacturer  will  not  be  able  to  manage  the  problem  alone,  it  will  have  to  inform  the  customer  and  decide  with  it  what 
steps  to  take.  This  is  also  part  of  the  “right  decision”. 

It  is  well  known  that  in  a  company,  the  key  to  reactivity  is  organisation. 

However,  this  is  also  where  the  main  difficulty  lies  when  it  comes  to  obsolescence.  Reactivity  in  the  event  of 
obsolescence  requires  the  implementation  of  a  fairly  complex  process  within  the  company  as: 

•  several  activities  are  involved: 

purchasing  (which  encounters  the  problem,  and  can  also  suggest  solutions), 

production  (which  has  to  be  reorganised), 

technical  (which  can  also  suggest  solutions), 

project  management  (which  has  to  arbitrate), 

sales  (if  there  are  sales  consequences), 

•  very  often  several  contracts,  or  even  several  products  are  affected,  so  that  the  optimum  decision  must  be  made  by 
several  people  in  the  light  of  constraints  (volumes,  deadlines,  customer  wishes,  etc.)  that  can  vary  significantly  from 
one  contract  to  another. 

Faced  with  this  problem,  the  Thomson-CSF  units  have  implemented  rather  varied  organisations. 

For  example,  in  a  unit  that  had  designed  a  strategy  of  modules  that  were  reusable  from  one  product  to  another,  the 
organisation  chosen  was  to  set  up  a  body  with  the  task  of  guaranteeing  the  supply  of  modules  to  the  products  in  spite  of 
obsolescence  problems.  This  body  finances  the  action  necessary  for  effective  obsolescence  management  with  a 
percentage  of  the  price  of  the  modules  delivered. 

In  another  unit  with  ASIC  based  products,  the  organisation  chosen  was  to  systematically  analyse  all  current  and 
foreseeable  needs  (raised  by  either  obsolescences  or  upgrading  policy)  for  every  product  so  that  every  ASIC  designed 
covers  as  many  of  these  as  possible. 

It  is  nevertheless  rather  difficult  to  transpose  such  best  practices  from  one  unit  to  another,  as  they  are  very  much  linked 
to  a  local  situation  (organisation,  type  of  product,  customer,  etc.). 

The  decision  within  the  Thomson-CSF  group  was  therefore  to  simply  collect  these  best  practices  together  and  make 
them  accessible  to  everyone,  but  purely  for  guidance. 
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However,  it  did  seem  useful  to  highlight  a  certain  number  of  rules  of  conduct.  These  rules  in  no  way  impose  a  type  of 
organisation.  They  form  a  list  of  questions  to  ask  in  order  to  judge  whether  or  not  a  type  of  organisation  is  appropriate. 
They  appear  in  a  document,  the  “Thomson-CSF  Baseline”,  which  groups  together  the  rules  that  all  units  should  follow, 
activity  by  activity. 

These  are  just  a  few  of  them: 

•  systematically  analyse  all  of  the  obsolescence  warnings, 

•  identify  their  impact  on  all  of  the  equipment, 

•  immediately  analyse  the  consequences  of  this, 

•  take  into  account  all  of  the  contracts  and  products  affected, 

•  take  advantage  of  the  synergies  between  products  to  combine  equipment  upgrades  and  obsolescence  management, 

•  make  sure  that  the  decisions  taken  are  followed  up  in  the  deadlines, 

•  in  particular,  comply  with  the  LBO  dates, 

•  inform  sales  of  the  consequences  of  obsolescence  on  costs  and  deadlines. 

As  will  be  seen,  these  are  all  very  obvious,  if  not  banal,  points.  However,  when  these  rules  were  drawn  up  in  1994- 
1995,  they  had  their  uses.  Although  they  are  easy  to  say,  they  are  much  more  difficult  to  implement  in  a  complex 
organisation.  Readers  with  experience  in  industry  will  doubtless  agree. 

4.3.2  Ability  to  anticipate  problems 

Given  the  complexity  of  the  process  mentioned  earlier  (gathering  of  information  +  decision  making),  obsolescence 
warning  times  that  might  seem  quite  comfortable  (typically  3  to  6  months)  are  in  fact  very  short,  so  the  final  decision  is 
often  taken  urgently. 

A  good  way  to  increase  reactivity  is  to  know  how  to  anticipate  the  problem. 

This  is  why  it  is  beneficial,  as  mentioned  in  §3.2,  to  review  the  part  list  for  every  piece  of  equipment  regularly  (every  12 
months)  in  order  to: 

•  analyse  the  predicted  end  of  life  date  of  each  component  in  the  equipment, 

•  update  the  sales  projections  for  the  equipment, 

•  depending  on  these  two  analyses,  update  the  projected  redesign  dates  and  the  course  of  action  to  be  taken  until  the 
next  date. 

Moreover,  anticipating  problems  through  systematic  part  list  reviews  is  not  just  a  way  of  increasing  reactivity.  As 
pointed  out  in  §3.2,  it  is  also  a  way  of  finding  the  optimized  solution,  i.e.  a  solution  that,  instead  of  solving  problems 
individually  as  they  arise,  incorporates  them  into  a  more  general  and  probably  more  cost-effective  procedure. 


5.  Conclusion 

Controlling  obsolescence  problems,  i.e.  the  ability  to  offer  long-term  availability  and/or  upgradeability  (depending  on 
the  customer’s  requirements)  is  therefore  increasingly  seen  as  a  fundamental  component  of  professional  electronics 
manufacturers’  know-how. 

It  responds  to  increasingly  high  expectations  from  all  types  of  customer,  whether  domestic  or  export,  in  aerospace, 
defence,  telecommunications  or  industry. 

This  control  means  that  the  manufacturer  must  implement  an  organisation,  principles,  methods  and  tools  that  guarantee 
its  customers: 

•  a  systematic  attitude  of  risk  anticipation  and  limitation,  from  the  most  upstream  phases  to  the  most  downstream 
phases  of  a  programme,  in  order  to  set  out  the  most  pertinent  strategy  at  all  times, 

•  excellent  reactivity  to  deal  with  problems  quickly  and  effectively  when  they  arise, 

•  a  relationship  of  trust  between  the  manufacturer  and  its  customer,  in  which  the  manufacturer  keeps  the  customer 
informed  of  the  main  actual  or  potential  problems  and  advises  it  on  its  requirements,  so  that  these  requirements 
encourage  the  implementation  of  an  effective  obsolescence  control  strategy. 

The  system  described  in  this  paper,  implemented  by  TTM  and  currently  fully  operational  within  Thomson-CSF,  shows 
how  common  tools  and  methods  can  greatly  help  each  of  the  units  in  the  group  offer  every  customer  the  most 
professional  and  cost  effective  process  to  guarantee  this  level  of  obsolescence  control. 

This  system  must  itself  come  within  the  framework  of  organisation  and  processes  specific  to  each  unit,  as  they  depend 
to  a  large  extent  on  the  specific  context  of  each  field,  market  and  customer. 

The  Thomson-CSF  group  is  willing  to  allow  other  manufacturers  to  use  all  or  part  of  this  system  within  the  framework 
of  a  partnership  agreement,  and  to  reap  its  benefits. 
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1  SUMMARY 

This  paper  presents  an  incremental  approach  towards 
the  adoption  of  an  Integrated  Modular  Avionics 
(IMA)  architecture,  via  the  implementation  of  a 
Mission  Management  System  using  present-day 
Commercial  Off-The  Shelf  (COTS)  technology. 

While  standardised  IMA  modules  are  planned  to  be 
developed  in  the  medium  term,  the  approach 
presented  enables  the  maximum  benefits  to  be 
obtained  from  those  aspects  of  the  IMA  concepts 
which  are  the  most  advanced,  while  exploiting  the 
availability  of  today's  COTS  hardware.  This  approach 
is  embodied  in  the  Mission  Management  System, 
which  is  under  development  at  ESG. 

The  Mission  Management  System  is  a  computer- 
based  system  which  is  intended  to  host  advanced 
mission  management  applications  focussed  on  crew 
assistance  functions,  including  mission  planning  and 
terrain-based  display.  The  hardware  of  the  Mission 
Management  System  comprises  a  single  unit,  the 
Mission  Management  Computer.  The  system,  and  in 
particular  its  software  structure  and  system 
management  functions,  are  based  on  the  IMA 
concepts  developed  in  the  ASAAC  (Allied 
Standardised  Avionics  Architecture  Council) 
programme,  which  are  applied  here  to  the  extent  that 
they  are  compatible  with  the  available  COTS 
components.  The  Mission  Management  System 
implements  those  elements  of  the  ASAAC  IMA 
concepts  that  are  most  suitable  for  near-term 
adoption,  and  in  particular  those  related  to  the 
software  structure,  which  is  based  on  the  use  of  a 
COTS  Real-Time  Operating  System. 

In  implementing  the  IMA  concepts  from  ASAAC,  the 
Mission  Management  System  is  designed  around  an 
open  system  architecture,  using  COTS  hardware  and 
software  components.  This  approach  provides 
technology  transparency,  and  supports  the  substitution 
of  system  components,  such  as  the  replacement  of 
system  hardware  or  the  Real-Time  Operating  System 
implementation,  to  mitigate  the  effects  of  hardware 
and  software  component  obsolescence. 

The  paper  first  presents  the  approach  adopted  in 
transitioning  towards  the  IMA  architecture  via  the  use 
of  current-day  COTS  components.  The  Mission 
Management  System  is  then  described  from  the 
system  architecture,  software  architecture  and 
hardware  architecture  points  of  view,  noting  the 
implementation  constraints  of  current  COTS 


components.  The  system  characteristics  which  are 
achieved  through  the  adoption  of  the  relevant  IMA 
principles  together  with  open  systems  and  COTS 
practices  are  presented. 

The  mission  management  functions  to  be 
implemented  on  the  system  are  defined,  and  an 
example  is  then  presented  of  a  complete  avionics 
system  built  using  the  transitional  technology  of  the 
Mission  Management  System  in  a  number  of 
Integrated  Computers  to  provide  a  complete 
computing  core. 

Some  certification  issues  are  discussed,  and  the 
adoption  of  an  incremental  certification  approach  is 
recommended.  A  path  forward  towards  the 
development  of  a  true  IMA  system  implementation  is 
proposed,  including  further  development  of  the 
Mission  Management  System,  and  the  migration  to  a 
modular  implementation. 

2  INTRODUCTION 

Integrated  Modular  Avionic  concepts  for  military 
aircraft  have  been  developed  under  a  number  of 
national  [Ref.  1]  and  international  projects,  the  latter 
including  in  particular  the  completed  European 
EUCLID  RTF  4.1  programme  [Ref.  2],  and  the  key 
ASAAC  programme  [Ref.  3,  Ref.  4,  Ref.  5]. 

The  IMA  concepts  developed,  and  particularly  those 
of  the  ASAAC  programme,  are  based  on  the 
principles  of  modular  systems,  open  systems  and 
COTS.  In  an  IMA  architecture,  the  computing 
capacity  is  concentrated  into  a  'Core',  which  consists 
of  interchangeable  processing  modules  of  a  limited 
number  of  standardised  types,  particularly  for  data, 
signal  and  graphics  processing.  IMA  systems  provide 
a  high  level  of  technology  transparency  by  being 
based  on  a  set  of  open  standardised  interfaces,  so 
facilitating  the  replacement  of  hardware  components 
without  affecting  the  application  software.  In 
addition,  the  use  of  open  standardised  interfaces 
directly  supports  the  use  of  COTS  components,  which 
is  of  great  benefit  in  combating  the  effects  of 
component  obsolescence.  IMA  systems  also 
implement  fault  tolerance,  so  that  when  a  module 
becomes  defective,  the  system  reconfigures  and  a 
spare  module  takes  over  the  functionality  of  the  failed 
module.  The  IMA  concepts  developed  in  the  ASAAC 
programme  have  been  adopted  as  the  basis  for  the 
Mission  Management  System  reported  on  in  this 
paper. 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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The  development  of  the  required  set  of  ASAAC  IMA 
hardware  modules  will  be  a  substantial  task,  and  its 
completion  lies  some  way  off  in  the  future.  Even 
given  the  availability  of  hardware  modules,  a  very 
considerable  certification  effort  will  be  required  to 
qualify  an  ASAAC  IMA-based  system,  particularly 
due  to  the  system-wide  configurability  under  software 
control  it  exhibits. 

It  is,  however,  possible  to  exploit  the  elements  of  the 
ASAAC  IMA  system,  software  and  hardware 
concepts  which  will  have  been  developed  before  such 
a  stage  is  reached,  while  using  the  COTS-based 
board-level  hardware  components  available  today. 
Such  advanced  IMA  concepts  may  be  implemented  in 
systems  without  expending  significant  additional 
effort  in  comparison  with  a  more  conventionally 
based  solution.  In  this  way  a  significant  number  of  the 
benefits  promised  by  the  IMA  architecture  may  be 
achieved  today:  a  key  example  is  the  use  of 
technology  transparency  to  combat  obsolescence. 

A  transitional  step  towards  the  implementation  of  the 
true  IMA  architecture  is  therefore  now  being  taken 
with  the  development  of  a  Mission  Management 
System.  In  defining  the  Mission  Management  System, 
the  aim  has  been  to  define  a  demonstrator  which  will 
allow  the  implementation  of  a  representative  set  of 
application  functions,  using  an  architecture  based  on 
the  IMA  architecture  of  ASAAC.  This  will  permit 
progress  to  be  made  towards  the  implementation  and 
certification  of  an  IMA-based  avionics  system,  by 
gaining  experience  in  the  implementation  of  an 
ASAAC  IMA-based  software  structure,  and 
evaluating  the  consequences  of  hosting  applications 
on  such  a  structure. 

The  Mission  Management  System  is  designed  to 
exploit: 

•  The  ASAAC  IMA  concepts: 

Currently  available  elements  of  the  ASAAC  IMA 
concepts  have  been  realised. 

•  Open  system  architectures: 

In  accordance  with  the  principle  of  offering  an 
open  architecture,  open  standards  have  been 
adopted.  The  use  of  an  open  architecture  supports 
especially  technology  transparency,  application 
portability  and  system  scalability. 

•  Available  COTS  hardware  and  software 
technology: 

Extensive  use  is  made  in  the  Mission  Management 
System  of  COTS  components,  both  hardware  and 
software.  The  use  of  COTS  supports  particularly 
the  lowering  of  system  costs  and  reduction  of 
development  time. 

By  the  adoption  of  these  concepts  in  the  Mission 
Management  System,  it  is  aimed  to  achieve  the 
following  characteristics  typical  of  IMA  systems: 


•  Application  Portability: 

The  portability  of  application  functions  between 
hardware  platforms  is  supported  in  turn  by 
technology  transparency. 

•  Technology  Transparency: 

Technology  transparency  embraces  hardware 
independence,  which  supports  hardware 
replacement  for  future  system  upgrading  and  to 
counter  component  obsolescence,  network 
independence,  which  enables  the  network 
technology  to  be  upgraded,  and  also  extends  to  the 
software  technology. 

•  Scalability: 

Scalability  supports  the  application  to  avionic 
systems  of  different  sizes  and  roles,  as  well  as 
future  avionic  system  growth.  The  scalability 
characteristic  is  in  turn  supported  by  technology 
transparency,  in  particular  by  hardware  and 
network  independence. 

•  System  Reconfigurability: 

By  reconfiguring  the  system  depending  on  the 
system  mode,  the  total  resource  requirements  of 
the  system  may  be  reduced.  Reconfigurability  may 
be  used  on  the  occurrence  of  faults  to  support  fault 
tolerance. 

•  Fault  Tolerance: 

Eault  tolerance  may  be  used  to  improve  system 
reliability,  and  is  supported  in  turn  by  system 
reconfigurability. 

3  SYSTEM  ARCHITECTURAL  CONCEPT 
3.1  Key  Concepts 

The  architecture  of  the  Mission  Management  System 
(MMS)  is  a  transitional  architecture  between  that  of 
the  current  generation  of  federated  architectures,  and 
future  IMA  architectures.  It  is  designed  to  be 
compatible  with  the  avionics  system  architectures  of 
both  new-build  aircraft  designs  and  retrofit 
applications. 

The  architecture  defined  for  the  MMS  utilises  the 
elements  of  the  ASAAC  concepts  which  are  the  most 
advanced,  but  which  are  also  compatible  with 
conventional  federated  avionics  systems.  The  aspects 
of  the  ASAAC  concepts  which  have  been  adopted  lie 
mainly  in  the  Software  Architecture  and  System 
Management  areas,  although  some  aspects  of  the 
hardware  concepts  have  also  been  employed.  The 
following  key  concepts  have  been  applied: 

•  Use  of  a  standardised  interface  between 
Application  Software  and  the  Operating  System 
Layer. 

•  Hardware  abstraction  by  software. 

•  Use  of  a  system  management  structure  and 
'Blueprints'  which  together  support  system 
configuration  and  reconfiguration. 
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•  Use  of  a  standardised  software  interface  for  all 
data  communication. 

Due  to  the  requirement  to  be  able  to  integrate  the 
MMS  within  a  conventional  federated  avionics 
system,  the  aspects  of  the  ASAAC  IMA  concepts 
which  extend  throughout  the  entire  avionics  system 
have  necessarily  found  only  partial  application.  These 
include  for  instance  the  system  health  and 
configuration  management  concepts. 

3.2  Open  Architecture 

Open  architectures  are  characterised  by  the  use  of 
widely  accepted  and  supported  standards  set  by 
recognised  standards  organisation  or  the  commercial 
market  place.  As  the  standards  are  available  to  all,  a 
system  based  on  an  open  architecture  is  open  to  the 
incorporation  of  components  from  potentially  any 
source.  The  IMA  architecture  defined  in  ASAAC  is 
such  an  open  architecture,  as  it  both  defines  its  own 
open  standards,  and  supports  the  use  of  available  open 
standards  in  its  implementation. 

An  ASAAC  IMA  system  may  be  regarded  as 
comprising  a  set  of  application  functions  hosted  on  an 
open  architecture  platform.  The  applications  are  not 
dependent  on  the  underlying  technology  and 
hardware,  as  the  interface  between  the  applications 
and  the  system  functions  is  established  as  an  open 
standard,  so  allowing  different  manufacturers  of 
software  and  hardware  components  to  contribute  to 
the  system. 

A  common  example  of  an  open  architecture  in  the 
commercial  world  is  the  POSIX  system  [Ref.  6], 
which  allows  Unix  systems  and  applications  to  be 
developed  independently  of  the  underlying  hardware, 
regardless  of  the  hardware  manufacturer.  While 
POSIX  is  unsuitable  for  an  IMA  System,  which 
requires  fully  predictable  real-time  behaviour  of  its 
components,  applications  in  ASAAC  IMA  systems 
are  hosted  on  an  open  platform  with  an  open 
interface,  the  Application  to  Operating  System  layer 
(APOS)  interface  (see  Sec.  4.3). 

3.3  Modes  and  Configurations 

In  the  MMS,  the  various  mission  management 
functions  are  each  only  required  to  operate  during  the 
relevant  phases  of  the  aircraft's  mission.  For  example, 
different  mission  planning  functions  are  likely  to  be 
applicable  to  different  mission  phases,  and  display 
functions  for  high-altitude  combat  air  patrol  would 
differ  from  those  for  low-level  target  ingress. 

In  order  to  optimise  the  utilisation  of  the  hardware 
resources  in  the  MMS,  and  so  reduce  the  total  system 
resource  requirements,  the  same  hardware  in  the 
MMS  will  be  used  to  host  different  application 
functions  at  different  times,  according  to  the 
requirements  of  the  mission  phase. 

Because  of  the  strict  separation  of  application 
function  design  from  the  system  hardware  design,  it  is 
possible  for  the  MMS  application  functions  to  be 


distributed  over  the  hardware  in  a  number  of  different 
ways,  and  hence  for  an  application  to  be  easily 
transferred  from  one  processor  to  another. 

At  the  transition  from  one  mission  phase  to  another 
the  MMS  will  be  reconfigured  by  halting  and 
removing  the  relevant  software  components  from  the 
processors,  and  loading  and  starting  new  components 
from  the  Mass  Memory  Unit. 

A  set  of  MMS  modes  is  defined  to  cover  the  various 
phases  of  the  mission,  where  a  specific  set  of 
functions  runs  in  each  mode.  Within  each  mode,  a 
number  of  different  configurations  of  the  functions  on 
the  various  hardware  resources  may  also  be  possible. 

3.4  Fault  Tolerance 

ASAAC  IMA  systems  offer  fault  tolerance  by 
reconfiguring  on  the  occurrence  of  faults.  A  new 
module  may  be  substituted  for  a  faulty  module,  and 
the  application  functions  reconfigured  accordingly. 
The  fault  tolerance  concept  of  the  MMS  is  derived 
from  that  of  ASAAC  IMA  systems. 

It  is  not  possible  to  implement  the  same  degree  of 
redundancy  in  the  MMS  as  in  the  ASAAC  IMA 
concept,  as  the  latter  relies  on  full  hardware 
redundancy  between  modules.  The  components  of  the 
MMS,  on  the  other  hand,  are  integrated  with  one 
another  at  a  lower  level:  powering  on  and  off 
individual  hardware  components  is  not  supported 
within  the  MMS,  for  instance. 

The  MMS  implements  a  limited  degree  of  fault 
tolerance.  Some  redundancy  is  likely  to  be  available 
between  the  multiple  instances  of  the  various 
hardware  components,  such  as  the  Single  Board 
Computers  (SBCs)  which  are  used  within  the  MMS. 
Where  such  redundant  capacity  is  available,  when  a 
component  becomes  defective,  the  system  is 
reconfigured  so  that  a  spare  component  takes  over  the 
functionality  of  the  failed  one.  Alternatively,  where 
no  extra  resources  are  available,  non-critical  functions 
may  be  dropped,  to  free  resources  for  higher  priority 
functions,  or  reversionary  implementations  of 
functions,  with  lower  resource  requirements,  may  be 
used.  In  this  way,  a  significantly  greater  fault 
tolerance  capability  is  achieved  than  with 
conventional  systems. 

3.5  System  Management 

ASAAC  IMA  systems  implement  a  standardised 
system  management  structure  that  is  responsible  for 
performing  the  following  major  functions: 

•  Initialisation  and  shutdown  management. 

•  Configuration  management,  including 
reconfiguration  on  mission  mode  transitions  and 
on  faults. 

•  Fault  management,  including  health  management 
such  as  the  processing  of  Built-In  Test  (BIT) 
data. 
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For  the  Mission  Management  System,  elements  of  the 
ASAAC  IMA  system  management  have  been  adopted 
as  appropriate.  Whereas  the  ASAAC  system 
management  concepts,  such  as  for  instance  health 
management  and  configuration  management, 
generally  encompass  the  entire  avionics  system,  it  has 
only  been  possible  to  implement  these  within  the 
scope  of  the  MMS. 

One  of  the  prime  responsibilities  of  system 
management  is  managing  the  control  of  the 
application  functions,  which  includes  their 
instantiation,  start,  suspension  and  removal  from  the 
system.  System  management  is  also  responsible  for 
configuring  communications  between  applications, 
which  is  performed  in  a  similar  manner  to  the  process 
scheduling,  in  order  to  guarantee  predictable 
communications. 


•  Only  limited  reconfiguration  is  supported, 
particularly  for  fault  tolerance. 

•  The  ASAAC  System  Management  Blueprint 
(SMBP)  interface  between  the  GSM  and  the 
blueprint  data  is  not  implemented. 

The  system  management  functions  are  implemented 
by  the  software  of  the  Generic  System  Management 
(GSM:  see  Sec.  4)  together  with  the  blueprint  data, 
which  are  provided  as  part  of  the  software  load. 

4  SOFTWARE  ARCHITECTURE 

4.1  The  ASAAC  Software  Architecture 

The  software  architecture  of  the  Mission  Management 
System  is  based  on  the  ASAAC  software  architecture, 
modified  to  suit  the  COTS-based  hardware 
architecture  of  the  MMS. 


The  system  management  functions  manage  the  system 
in  accordance  with  the  blueprints.  The  blueprints 
provide  the  definition  of  the  system  resources,  and 
define  the  possible  configurations  of  the  system.  The 
configurations  are  deterministic,  and  are  defined  at 
design  time:  such  strict  system  control  will  be 
necessary  in  order  to  certify  the  system.  As  well  as  the 
configurations  themselves,  the  blueprints  also  define 
the  reconfiguration  processes  which  are  carried  out  on 
the  occurrence  of  faults. 

System  management  in  the  ASAAC  IMA  concept  is 
performed  throughout  the  avionics  system  on  a 
hierarchical  basis.  In  the  MMS,  system  management 
is  performed  at  two  levels.  The  top-level  manager  is 
the  System  Manager,  and  this  controls  the  Resource 
Manager,  which  manages  a  particular  single  board 
computer  hosting  a  number  of  application  functions. 
Figure  1  shows  the  MMS  system  management 
hierarchy. 
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Figure  1 :  System  Management  Hierarchy 

The  MMS  system  management  differs  from  that  of 
the  ASAAC  concepts  primarily  as  follows: 

•  The  system  manager  hierarchy  is  limited  to  two 
levels. 

•  Fault  detection  is  dependent  on  the  capabilities  of 
the  COTS  components. 
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Figure  2:  The  ASAAC  Software  Architecture 

The  main  components  of  the  ASAAC  software 
architecture  are  the  Application  Functions,  the 
Operating  System  (OS),  the  Generic  System 
Management  (GSM)  and  the  Runtime  Blueprint 
representation  (RTBP),  as  depicted  in  Figure  2.  The 
GSM  defines  and  manages  the  processing  and 
communication  resources  required  by  the  application, 
and  the  operating  system  provides  the  application 
with  access  to  these  resources.  The  blueprints  provide 
the  definition  of  the  resources  and  of  the  possible 
system  configurations.  The  GSM  and  the  runtime 
blueprints  are  associated  with  both  the  system 
hardware  and  the  application-independent  operating 
system  layer. 
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This  architecture  is  based  on  the  principle  of  a  three- 
layer  software  stack,  where  the  layers  have  the 
following  properties: 

•  Application  Layer 

Application  Dependent,  Hardware  Independent 

•  Operating  System  Layer 

Application  Independent,  Hardware  Independent 

•  Module  Support  Layer 

Application  Independent,  Hardware  Dependent. 

This  architecture  as  implemented  in  the  MMS  is 
illustrated  by  Figure  3. 
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Figure  3:  Design  of  the  MMS  Software  Stack 

In  this  design,  the  ASAAC  software  architecture  has 
been  adapted  to  the  requirements  and  constraints  of  a 
computer  architecture  based  on  COTS  VME  hardware 
and  a  COTS  real-time  operating  system: 

•  There  is  no  Module  Support  Layer:  hardware 
abstraction  is  achieved  by  the  architecture  of  the 
real-time  operating  system. 

•  The  GSM  function  is  simplified  into  two  kinds  of 
management  functions,  a  top  level  System 
Manager,  which  controls  the  overall  computer, 
and  a  Resource  Manager  for  every  single  board 
computer,  which  controls  the  board  local 
resources. 

4.2  Hardware  Abstraction 

A  prime  property  of  the  ASAAC  software 
architecture  is  the  independence  of  the  application 
software  from  the  hardware,  as  the  highest  costs  that 
arise  in  the  replacement  of  obsolete  hardware  are 
incurred  in  the  consequential  adaptation  of  the 
application  software. 


In  the  ASAAC  software  architecture,  a  hardware 
abstraction  layer  is  provided  in  the  form  of  the 
Module  Support  Layer  (MSL).  This  hardware 
abstraction  provides  the  system  with  hardware 
independence:  the  higher  software  layers  are 
independent  from  the  hardware  details,  so  that 
hardware  changes  do  not  affect  either  the  operating 
system  layer  or  the  application  layer  software,  so 
countering  the  effects  of  component  obsolescence.  In 
the  Mission  Management  Computer,  this  architecture 
has  been  adapted  to  the  architecture  of  a  COTS  real¬ 
time  operating  system.  This  adaptation  provides  the 
same  hardware  abstraction  characteristics  as  specified 
for  the  Module  Support  Layer. 

This  hardware  independence  is  provided  at  the  level 
of  source  code  compatibility,  as  binary  compatibility 
would  require  a  much  higher  degree  of 
standardisation.  Standardisation  down  to  the  level  of 
binary  compatibility  has  to  be  very  detailed,  and  is 
therefore  very  restrictive,  so  limiting  the  openness  of 
the  architecture.  Source  code  compatibility  appears 
for  this  reason  to  be  the  appropriate  choice. 

In  addition  to  the  issue  of  source  code  compatibility, 
hardware  modifications  are  likely  to  result  in  changes 
in  the  resource  characteristics  of  the  hardware,  such 
as  enhancements  to  the  processing  power  or 
communication  capacity,  which  would  affect  the 
system  operation.  This  issue  is  addressed  by 
separating  the  configuration  data  from  the  system 
management  functions,  and  encapsulating  it  in  the 
form  of  blueprints.  A  change  of  hardware  or  the 
porting  of  an  application  to  another  system  would 
therefore  only  require  the  adaptation  of  the  blueprints 
and  the  recompilation  of  the  relevant  software, 
including  the  operating  system  layer  and  application 
code. 

4.3  The  Operating  System  Layer 

The  Operating  System  Layer  includes  the  Operating 
System  itself,  together  with  the  system  management 
components,  ie.  the  system  managers  and  the  run-time 
representation  of  the  system’s  blueprints. 

One  of  the  chief  benefits  from  the  use  of  the  ASAAC 
software  architecture  for  the  Mission  Management 
System  is  application  portability,  which  supports  the 
reuse  of  the  application  software.  Application 
portability  is  provided  primarily  by  the  use  of  a 
standardised  Application  to  Operating  System 
(APOS)  layer  interface.  As  it  is  the  only  interface  of 
the  ASAAC  software  architecture  visible  to  the 
application,  the  application  is  dependent  only  on  this 
interface  for  the  satisfaction  of  its  processing  and 
communication  resource  requirements.  As  the 
Mission  Management  System  offers  the  same  APOS 
as  any  ASAAC  system,  the  mission  management 
applications  are  therefore  portable  to  other  systems 
built  using  the  ASAAC  standards. 

A  COTS  real-time  operating  system  is  used  as  the 
core  of  the  operating  system  layer.  In  comparison 
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with  the  alternative  approach,  which  is  the 
development  of  a  bespoke  operating  system,  the 
COTS  approach  exhibits  greater  flexibility  and  cost 
efficiency  due  to  the  commercial  support  provided  for 
the  adaptation  to  new  hardware  components.  The  use 
of  a  COTS  operating  system  supports  the  efficient 
implementation  of  the  operating  system  layer  on  the 
underlying  COTS  hardware,  both  for  the  MMS 
hardware,  and  for  AS  A  AC  IMA  systems.  A  COTS 
Real-Time  Operating  System  is  therefore  well  suited 
to  support  the  transition  from  the  federated  system 
architecture  of  the  MMS  to  an  IMA  system,  providing 
a  stable  Application  Programming  Interface  together 
with  off-the-shelf  compatibility  with  COTS  hardware. 

The  COTS  operating  system  is  complemented  in  the 
operating  system  layer  by  additional  software  which 
provides  the  adaptation  to  the  ASAAC  operating 
system  interfaces,  and  in  particular  to  the  APOS. 

4.4  Application  Function  Software  Structure 

The  application  process  is  the  basic  software  element 
of  an  application  function,  and  represents  the 
configuration  unit  of  a  system.  Each  application 
process  depends  on  processing  and  communication 
resources,  namely  on  threads  and  virtual  channels, 
and  can  only  be  executed  when  the  system 
management  function  provides  its  required  processing 
and  communication  resources. 

In  the  Mission  Management  System,  three  different 
kinds  of  application  processes  have  to  be 
accommodated;  data  processing  processes,  graphics 
processes  and  mass  memory  -related  processes.  The 
last  of  these  includes  such  processes  as  database 
applications,  and  is  implemented  in  the  form  of  file 
access  functions.  While  data  processing  and  mass 
memory  applications  may  be  freely  located  on  any 
processor,  graphics  processing  is  restricted  to  the 
specific  hardware  capable  of  providing  the  OpenGL 
interface  and  functionality. 

The  mission  management  application  is  built  from  a 
number  of  small  but  simple  processes,  most  of  which 
contain  only  a  single  thread,  and  which  are  configured 
in  accordance  with  the  currently  active  mission  mode. 
Each  of  these  processes  depends  on  both  transient 
data  and  persistent  information:  the  transient  data  is 
provided  via  the  MMS  interface,  and  the  persistent 
information  from  a  central  database,  which  is 
represented  by  an  application  process  that  provides 
information  on  request. 

4.5  Properties  of  the  Software  Architecture 

The  software  architecture  of  the  MMS  offers  a 
number  of  beneficial  properties  in  comparison  with 
conventional  systems. 

Application  portability  and  technology  transparency 
are  both  provided  by  the  use  of  the  APOS  as  a 
standardised  interface  between  the  application 
software  and  the  operating  system  layer.  This  permits 
the  reuse  of  the  application  software  on  other  systems 


offering  the  ASAAC  APOS  interface,  and  also  the 
replacement  of  the  MMS  hardware  without 
modification  of  the  application  software  source  code. 
Performing  the  application  design  independently  of 
the  underlying  hardware  is  also  supported. 

In  addition,  hardware  abstraction  below  the  level  of 
the  APOS  provides  protection  against  component 
obsolescence,  by  supporting  hardware  independence. 

Technology  transparency  in  the  MMS  also  extends  to 
software  technologies:  as  the  APOS  is  independent  of 
the  underlying  COTS  OS  used,  the  COTS  OS  may 
also  be  replaced  without  affecting  the  application 
functions. 

The  GSM  and  blueprints  support  the  ability  to 
reconfigure  the  system  in  accordance  with  the  mission 
requirements,  so  providing  for  efficient  hardware  use, 
and  also  supporting  fault  tolerance,  which  contributes 
to  improved  system  reliability. 

The  open  standards  used  include  the  open  commercial 
standard  OpenGL,  and  the  ASAAC  standards.  COTS 
components  used  include  the  COTS  operating  system, 
together  with  its  board  support  packages  and  drivers. 

Due  to  the  intention  to  maximise  the  use  of  COTS 
components  in  the  development  of  ASAAC  modules, 
the  approach  adopted  for  the  Mission  Management 
Computer  of  employing  the  ASAAC  software  stack 
with  a  COTS  operating  system  is  likely  to  remain 
effective  throughout  the  continuing  transition  from 
today’s  federated  system  architecture  to  tomorrow’s 
IMA  architectures. 

5  HARDWARE  ARCHITECTURE 

5.1  The  Mission  Management  Computer 

While  current  work  is  focussed  on  the  software 
structure,  using  laboratory  development  hardware,  the 
Mission  Management  Computer  (MMC),  which 
would  form  the  hardware  of  the  Mission  Management 
System  in  a  real  aircraft  application,  and  on  which  the 
application  functions  would  run,  has  also  been 
defined. 

In  an  avionics  system  application,  the  Mission 
Management  System  would  be  integrated  with  and 
exchange  data  with  other  avionics  system  computers 
and  peripheral  devices,  including  sensors,  effectors 
and  displays  and  controls:  a  possible  system 
implementation  is  shown  in  Sec.  7. 

In  order  for  the  MMS  to  be  able  to  perform  the 
required  application  functions,  the  MMC  must 
support  the  relevant  low-level  functions,  which 
include  data  processing,  graphic  display  processing, 
provision  of  mass  memory,  and  communication.  The 
MMC  has  been  defined  for  hosting  the  MMS 
functions  discussed  in  Sec.  6. 

5.2  Structure  and  Packaging 

The  packaging  concept  of  the  MMC  differs 
considerably  from  that  of  IMA  systems.  Whereas  in 
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an  IMA  system,  the  line-replaceable  items  are  the 
individual  modules,  the  MMC  is,  in  line  with 
contemporary  avionic  systems,  itself  the  line- 
replaceable  item. 

The  basic  principle  behind  the  construction  of  the 
MMC  is  the  exploitation  of  available  COTS 
components,  and  in  particular  the  use  of  VME  boards. 
This  enables  the  demonstrator  to  be  built  using 
standard  commercial  grade  racks  and  boards,  and  a 
ruggedised  version  suitable  for  service  use  to  be 
produced  using  components  qualified  to  the 
appropriate  environmental  standards.  In  an  aircraft 
application,  the  MMC  would  take  the  form  of  a 
standard  ATR  format  unit,  which  would  be  mounted 
on  an  ATR  rack  in  the  avionics  bay. 

While  the  application  of  the  IMA  hardware  concepts 
to  the  MMS  is  limited  by  the  use  of  pure  COTS 
hardware  for  the  MMC,  the  hardware  structure  of  the 
MMC  has  been  influenced  by  the  ASAAC  concepts 
where  possible,  in  order  to  support  the  ASAAC 
software  and  system  architecture  concepts  employed, 
and  to  support  the  future  development  path  towards 
an  IMA  system. 

The  structure  of  the  MMC  therefore  conforms  with 
the  ASAAC  concepts  in  the  segregation  of  the  data 
processing,  graphics  processing  and  mass-memory 
capabilities.  Areas  in  which  the  structure  of  the  MMC 
diverges  from  the  ASAAC  structure  include  the 
separation  of  the  external  communications  interface 
from  the  processing  capacity,  and  the  lack  of  a 
Module  Support  Unit  local  to  each  of  the  processors. 
Power-Up  and  Continual  Built-In  Test  are 
implemented  to  the  degree  that  these  are  supported  by 
the  COTS  hardware. 

The  structure  of  the  MMC  is  shown  in  Figure  4 
below,  and  discussed  in  the  following  text.  The  MMC 
is  constructed  using  64-bit  VME  boards:  where 
required,  for  instance  for  communications,  PMC 
modules  are  mounted  on  the  VME  cards. 
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Figure  4:  The  Mission  Management  Computer 


•  Data  Processing  Unit 

•  Graphics  Processing  Unit 

•  Mass  Memory  Unit 

•  Communications  Unit. 

The  data  processing  hardware  comprises  three  Data 
Processing  Units,  each  taking  the  form  of  a  PowerPC 
Single  Board  Computer  (SBC). 

The  graphic  display  processing  implements  three 
graphics  processing  channels,  and  so  provides  the 
capability  of  driving  three  displays  with  separate 
formats.  The  graphics  processing  hardware  comprises 
a  Graphics  Processing  Unit,  consisting  of  three  3D 
graphics  PMCs  supporting  OpenGL,  mounted  on  a 
PowerPC  SBC.  Each  graphics  processor  PMC 
provides  the  following  key  features: 

•  OpenGL  implementation 

•  1024  X  1024  resolution 

•  1  M  three-dimensional-polygons  /  sec. 

The  Mass  Memory  Unit  is  implemented  as  a  solid 
state  memory  or  hard  disk  interfaced  with  a  PowerPC 
SBC. 

The  Communications  Unit  consists  of  the  relevant 
network  interfaces  implemented  as  PMC  modules 
mounted  on  a  PowerPC  SBC:  in  addition,  analogue 
and  discrete  input  /  output  is  provided  for  as  required. 

5.4  Data  Communications 

All  data  communication  within  the  MMS  between 
processor  boards  and  between  the  MMS  and  external 
equipment  takes  place  via  a  standardised  software 
network  interface,  termed  the  Network  Independent 
Interface  (Nil),  which  has  been  derived  as  part  of  the 
ASAAC  concepts.  Data  transfer  takes  place  through 
the  Nil  via  a  Transfer  Connection  (TC),  which  acts  as 
a  virtual  channel,  and  which  is  established  explicitly 
prior  to  the  data  transfer. 

The  use  of  the  Network  Independent  Interface 
provides  the  ability  to  change  the  network  technology 
used,  for  instance  when  reconfiguring  the  system  and 
re-routing  a  particular  transfer  from  an  MMS -internal 
transfer  to  an  external  transfer.  The  network 
technology  used  for  external  transfers  might  also  be 
upgraded  as  part  of  a  future  system  improvement. 

Communications  within  the  MMC  takes  place  using 
the  buses  available  with  the  COTS  boards,  such  as  the 
VME  and  PCI  buses. 

The  network  technology  used  for  external 
communication  depends  on  the  particular  avionics 
system  implementation  into  which  the  MMS  is 
integrated:  options  range  from  the  conventional  Mil- 
Std  1553  command  /  response  bus  or  ARINC  429  data 
distribution  bus,  to  a  high-capacity  optical  serial 
COTS  Fibre  Channel  network. 


5.3  Hardware  Components 

The  MMC  consists  of  four  main  types  of  VME-bus 
component: 
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5.5  Properties  of  the  Hardware  Architecture 

The  hardware  architecture  of  the  MMS  offers  a 
number  of  beneficial  properties  in  comparison  with 
conventional  systems. 

Technology  transparency  is  supported  by  the  Network 
Independent  Interface,  which  provides  for  the 
replacement  of  the  network  technologies  used  while 
maintaining  the  software  interface  to  the  network,  so 
allowing  for  data  transfer  growth. 

Support  is  provided  for  scalability  and  system  growth, 
particularly  by  the  use  of  an  open  COTS-based 
architecture.  The  MMC  is  capable  of  being  extended 
to  cater  for  the  addition  of  further  MMS  functionality, 
should  this  be  required  for  a  particular  system 
application.  Further  data  processing  SBCs  may  be 
added  to  provide  the  required  capacity,  and  the 
number  of  graphics  processing  PMCs  may  be  chosen 
to  feed  the  number  of  displays  required.  Hardware 
components  of  the  computer  may  be  replaced, 
providing  that  the  availability  of  the  relevant  COTS 
operating  system,  board  support  package  and  drivers 
is  assured. 

Within  the  MMC,  a  limited  degree  of 
interchangeability  between  components  could  be 
offered  by  the  use  of  a  number  of  identical  VME 
SBCs  and  PMC  modules. 

Open  standards  used  in  the  MMC  include  open 
commercial  standards  as  ATR,  VME64,  PCI,  PMC 
and  Eibre  Channel,  open  military  standards  such  as 
Mil-Std-1553B,  and  the  ASAAC  standards. 

Use  is  made  of  Commercial  (COTS)  and  Military 
Off-The-Shelf  (MOTS)  components  as  follows: 

•  SBCs,  PMCs:  COTS  boards,  using  commercial 
chip-level  components. 

•  Network:  COTS,  MOTS. 

6  MMS  FUNCTIONALITY 

6.1  Generic  Mission  Management  Functions 

The  possible  system  applications  of  a  Mission 
Management  System  extend  across  a  range  of  aircraft 
roles,  from  combat  aircraft,  including  rotary  wing 
types,  to  heavier  patrol  and  transport  aircraft.  The 
specific  functions  implemented  on  the  Mission 
Management  System  in  a  particular  avionics  system 
implementation  would  depend  on  the  role  of  the 
aircraft  and  the  allocation  of  functionality  within  the 
complete  avionics  system. 

Typical  mission  management  functions  include  the 
following: 

•  Situation  Assessment 

•  Conflict  Management 

•  Mission  Planning 

•  Man-Machine  Interface 

•  Navigation 

•  Flight  Guidance. 


The  functional  structure  of  a  Mission  Management 
System  is  shown  in  Figure  5  below. 


Figure  5:  Functional  Components  of  a  Mission 
Management  System 


6.2  Functions  Selected 

For  the  Mission  Management  System  under 
development,  a  representative  set  of  functions  which 
is  broadly  aimed  at  a  multi-role  fighter  application  has 
been  chosen. 

The  primary  functions  selected  are  mission  planning, 
representing  a  high-performance  data  processing 
application,  and  the  production  and  presentation  of 
perspective  flight  guidance  information,  a  three- 
dimensional  graphic  application. 

These  functions  are  based  on  those  under 
development  in  parallel  activities  being  performed  at 
ESG,  as  previously  reported  [Ref.  7],  and  are  now  to 
be  ported  to  the  Mission  Management  Computer  from 
their  original  implementations  on  a  laboratory 
workstation-based  environment. 

To  provide  the  required  functionality,  the  Mission 
Management  System  will  comprise  the  following 
functional  components: 

•  Databases: 

•  Terrain  Database 

•  Navigation  Database 

•  Functional  components: 

•  Threat  Analysis 

•  Mission  Planner,  including: 

Transit  Planner 
Low-Level  Flight  Planner 
Attack  Planner 

•  Graphics  processing: 

•  Head-Up  Display  with  Terrain  Graphics 

•  Head-Down  Display  with  Synthetic  Vision 

•  Tactical  Navigation  Display. 

External  inputs  received  by  the  MMS  from  other 
avionics  system  components  include: 

•  Aircraft  Data  (eg.  Position,  Velocity,  etc.) 

•  Sensor  Data  (eg.  Threat  warnings,  Datalink). 

Details  of  the  functions  have  been  given  previously  in 
[Ref.  7]. 
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The  functional  structure  of  the  system  has  been 
designed  to  accommodate  the  addition  of  further 
functional  components  as  and  when  required, 
depending  on  the  requirements  of  the  anticipated 
application  avionics  system. 

7  AVIONICS  SYSTEM  ARCHITECTURE 

7.1  Architectural  Concepts 

This  section  addresses  the  system  architecture  of  an 
avionics  system  into  which  the  Mission  Management 
System  might  be  integrated.  The  system  example 
described  here  is  a  near-term  new  system  design, 
again  based  on  a  multi-role  fighter  application. 

The  proposed  system  architecture  is  based  on  the  use 
of  Integrated  Computers,  of  which  the  Mission 
Management  Computer  is  an  example,  each  based  on 
the  same  system,  software  and  hardware  architectures 
as  described  for  the  MMS  above. 

The  avionics  system  structure  remains  essentially  a 
federated  architecture.  As  in  conventional  federated 
systems,  the  overall  avionics  system  is  divided  into  a 
number  of  dedicated  systems  /  sub-systems,  eg. 
Mission  Management  System,  Stores  Management 
System.  The  overall  system  consists  of  a  number  of 
Integrated  Computers,  together  with  essentially  the 
same  dedicated  equipment  found  in  conventional 
federated  systems,  eg.  Radar,  Radio,  Displays  and 
Controls. 

The  computing  capacity  of  the  avionics  system  is 
distributed  between  the  Integrated  Computers,  which 
are  interconnected  via  the  communication  network.  In 
comparison  with  other  federated  architectures,  the 
Integrated  Computer-based  architecture  is 
characterised  by  the  centralisation  of  the  processing 
capacity  in  a  smaller  number  of  higher-capacity 
processors. 

Most  of  the  processing  of  the  sensor  data,  including 
the  signal  processing,  takes  place  in  the  sensor 
equipment  itself,  whereas  the  subsequent  system-level 
data  processing  of  the  sensor  data  is  performed  in  the 
Integrated  Computers.  The  degree  to  which  the  sensor 
data  processing  is  implemented  in  the  Integrated 
Computers  depends  on  the  capability  provided  by  the 
particular  sensors  themselves. 

System  management,  embracing  moding, 
configuration  management  and  fault  tolerance,  would 
initially  remain  implemented  largely  at  the  level  of 
the  Integrated  Computers,  rather  than  being  integrated 
at  an  aircraft  level,  as  with  an  ASAAC  IMA  system. 
However,  for  critical  functions  additional 
reversionary  implementations  with  reduced 
capabilities  could  be  hosted  on  alternative  computers. 

7.2  System  Structure 

Four  Integrated  Computers  form  the  core  of  the 
avionics  system,  connected  with  the  peripheral 
equipment,  including  sensors  and  effectors,  and 


displays  and  controls,  and  also  the  safety-critical 
Stores  Management  System. 

The  Integrated  Computers  perform  the  following 
roles: 

•  Interface  and  Monitoring  Processor 

•  Mission  Management  System 

•  Communications  Processor 

•  Defence,  Attack  and  Armament  Computer. 

The  structure  of  the  avionics  system  is  shown  in 
Figure  6  below.  The  equipment  shown  in  grey  is 
external  to  the  avionics  system. 


Figure  6:  Example  Avionics  System  Structure 

Due  to  the  high  level  of  integration  within  the 
Integrated  Computers,  the  data  transfer  loading 
between  the  individual  equipment  remains  relatively 
moderate.  Data  transfer  between  equipment  takes 
place  either  as  in  a  conventional  system  via  a 
Command  /  Response  or  Data  Distribution  Bus  (eg. 
Mil-Std  1553  or  ARINC  429),  or  by  the  use  of  a 
supplementary  Fibre  Channel  overlay  network,  which 
is  indicated  by  the  broad  lines  in  Figure  6.  The  latter 
provides  for  higher  data  rates  between  particular 
equipment,  where  these  are  required,  for  instance 
between  the  integrated  computers,  and  for  video  data. 

Interchangeability  between  the  various  Integrated 
Computers  could  be  provided  by  the  use  of  multiple 
instances  of  the  same  computer  design.  This  should  in 
principle  be  possible,  due  to  the  similarity  of  the 
requirements  for  the  various  system  computers. 

8  THE  PATH  FORWARD  TOWARDS  IMA 

8.1  Further  Development  of  the  MMS 

The  Mission  Management  System  defined  in  this 
paper  represents  a  significant  step  towards 
implementing  an  ASAAC  IMA  architecture,  a  goal 
which  is  to  be  achieved  with  the  introduction  of  the 
IMA  hardware  modules.  There  would,  however,  be  a 
number  of  potential  advantages  in  further  developing 
the  MMS  concept  by  adding  additional  IMA  features 
before  progressing  to  a  definitive  IMA  system: 
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•  Multiple  instances  of  Integrated  Computers 
similar  to  the  Mission  Management  System  could 
be  integrated  in  an  avionics  system,  as  shown  in 
Sec.  7.  The  implementation  of  the  ASAAC 
system  management  concept  could  be  extended 
incrementally  to  encompass  system-level 
management,  so  that  such  functions  as 
initialisation  and  reconfiguration  would  be 
performed  on  a  system-wide  basis. 

•  A  form  of  design-time  blueprints  could  be 
implemented,  containing  resource  requirements 
and  specifications,  to  provide  system  design 
support. 

•  When  available,  the  ASAAC  network  technology 
could  be  introduced,  to  provide  the  required  high 
capacity,  real-time  deterministic  behaviour,  and 
network  redundancy. 

•  Signal  processing  capability  might  also  be  added 
to  the  MMC,  following  the  IMA  strategy  of 
centralising  processing  in  the  core. 

8.2  Migration  to  an  IMA  Implementation 

The  eventual  implementation  of  a  system  with 
ASAAC  IMA  modules  will  result  in  fundamental 
efficiency  advantages  for  system  development  and 
operation,  due  to  the  use  of  a  standardised, 
interchangeable  hardware  set. 

The  example  system  implementation  presented  in  Sec. 
7,  based  on  the  use  of  four  Integrated  Computers, 
represents  an  architecture  which  could  be  migrated  to 
a  full  ASAAC  IMA  architecture,  by  the  replacement 
of  each  of  the  Integrated  Computers  by  an  IMA 
Integration  Area. 

The  use  of  individual  modules  will  improve  the 
hardware  efficiency  of  reliable  system  designs,  by 
permitting  system  reconfigurability  at  the  module 
level.  This  represents  a  significant  improvement, 
when  compared  with  non-modular  equipment  such  as 
the  MMC,  which  is  integrated  as  a  complete  unit,  and 
which  is  therefore  potentially  susceptible  to  single 
point  failures. 

8.3  IMA  Certification  Considerations 

Systems  such  as  the  Mission  Management  Computer 
that  are  based  on  IMA  principles  introduce  a  number 
of  new  factors,  including  in  particular  their 
reconfigurability,  which  are  likely  to  affect  their 
certification. 

With  traditional  systems,  certification  has  been 
achieved  for  the  complete  system,  including  both  its 
hardware  and  its  software.  Some  systems  have 
implemented  a  degree  of  reconfiguration,  but  with  a 
relatively  restricted  number  of  configuration  cases,  all 
of  which  have  usually  been  designed  into  the  system 
together  with  the  hardware  and  application  software, 
with  the  system  being  certified  as  a  whole. 

In  contrast,  in  the  ASAAC  IMA  system,  and  in  the 
MMS,  the  hardware,  operating  system  layer  software 
and  application  functions  are  to  be  developed 


separately,  with  well-defined  interfaces,  and 
configurations  determined  for  the  integrated  system. 

The  system  configurations  of  the  MMS  are 
deterministic,  in  that  all  possible  configurations  are 
determined  at  design  time,  and  stored  in  the 
blueprints.  The  total  number  of  system  configurations 
may  however  be  very  high,  as  the  overall  system 
configuration  is  made  up  of  all  the  individual 
processor  configurations,  and  as  the  processors  are 
configurable  at  the  level  of  individual  processes. 
While  it  will  be  necessary  to  certify  each  system 
configuration,  it  will  not  be  practical  to  verify  in 
detail  the  complete  correct  operation  of  an  integrated 
ASAAC  IMA  system  in  all  possible  modes.  This 
leads  to  the  proposal  to  adopt  a  new  approach  and 
perform  certification  incrementally  using  a 
component-based  method,  as  discussed  below. 

8.4  Incremental  Certification 

The  basic  principle  of  the  incremental  certification 
approach  is  to  be  able  to  modify  a  certified  system, 
and  to  achieve  certification  for  the  modified  system 
by  certifying  only  the  changes,  without  having  to 
repeat  the  full  certification  process  anew  on  the 
modified  system  in  its  entirety. 

In  order  to  be  able  to  perform  incremental 
certification,  it  is  necessary  to  constrain,  and  to  be 
able  to  identify,  the  effects  of  the  modifications  on  the 
original  certified  system.  In  this  way,  the  certification 
process  for  the  modified  system  may  be  concentrated 
on  the  changes  introduced  and  their  resulting 
consequences. 

Incremental  certification  can  be  applied  to  the 
development  of  completely  new  systems,  by 
performing  certification  of  the  system  at  various 
stages  in  its  development,  as  well  as  to  the 
modification  of  in-service  systems:  the  incremental 
certification  approach  is  particularly  applicable  to  the 
addition  of  application  functions  to  an  existing 
system. 

The  principle  of  incremental  certification  may  be 
further  developed  to  include  component-based 
certification.  Here,  the  basic  principle  is  that  each 
component  is  certified  in  its  own  right,  so  that  when  a 
system  is  assembled  out  of  a  number  of  components, 
it  is  then  just  the  integration  of  the  components  which 
needs  to  be  certified. 

8.5  MMS  Incremental  Certification 

It  is  proposed  to  adopt  a  component-based 
incremental  certification  approach  for  the  Mission 
Management  System.  The  main  characteristics  of  the 
Mission  Management  System  which  support 
incremental  certification  are  application  portability 
together  with  the  related  technology  transparency. 
These  characteristics  are  derived  primarily  from  the 
use  of  the  APOS,  the  Application  to  Operating 
System  layer  interface.  Due  to  the  definition  and 
standardisation  of  this  interface,  the  Application 


15-11 


Functions  are  decoupled  from  the  underlying 
operating  system,  hardware  and  drivers,  which  in  turn 
enables  the  certification  of  the  components  either  side 
of  the  APOS  to  be  decoupled. 

The  adoption  of  incremental  certification  will  require 
the  development  of  an  appropriate  certification 
process  by  the  certification  authorities,  and  it  is 
proposed  that  the  MMS  be  used  as  a  vehicle  for 
development  work  on  such  a  process. 

When  applying  the  principles  of  component-based 
incremental  certification  to  the  development  of  the 
MMS,  there  are  a  number  of  steps  which  may  be 
taken  to  ease  its  certification. 

Firstly,  the  application  functions,  in  particular  for  the 
first  MMS  implementation,  should  be  of  a  low 
criticality.  In  view  of  this,  those  that  have  been 
selected  for  the  MMS  are  non-  safety-critical,  and  do 
not  require  fail-safe  implementation  due  to  reliability 
considerations. 

Further,  due  to  the  concerns  regarding  the 
certification  of  reconfigurable  systems  discussed 
above,  it  might  be  advisable  to  limit  the  scope  of  the 
reconfiguration  mechanisms  implemented  in  the 
MMS,  in  order  to  ease  the  first  certification.  One 
potential  measure  would  be  to  limit  the  configurations 
to  a  small  number,  so  that  each  reconfiguration  step 
could  be  examined  in  detail.  A  further  measure  would 
be  to  exclude  all  fault-triggered  reconfiguration, 
leaving  only  reconfiguration  on  mission  mode 
changes.  Once  initial  certification  was  obtained,  the 
scope  of  the  reconfiguration  could  be  successively 
extended. 

9  CONCLUSIONS 

The  Mission  Management  System  described  in  this 
paper  and  being  prototyped  at  ESG  has  been  seen  to 
feature  an  effective  IMA-derived  architecture,  and  to 
offer  a  representative  set  of  mission  management 
functions. 

Through  the  adoption  of  the  IMA  principles  from  the 
ASAAC  programme,  and  their  implementation  using 
COTS  components  on  the  basis  of  an  open  system 
architecture,  the  Mission  Management  System  is  able 
to  offer  the  following  key  characteristics: 

•  Application  portability  is  achieved  by  the 
application  functions’  use  of  the  APOS  interface. 

•  Hardware  independence  is  provided  by  hardware 
abstraction,  and  provides  protection  against 
component  obsolescence. 

•  Reduced  development  time  and  lower  costs  are 
supported  by  the  use  of  COTS  components  and 
methods. 


A  number  of  further  valuable  properties  are  also 
realised: 

•  System  reconfigurability  is  provided  by  the 
system  management  function  and  blueprint  data, 
and  supports  the  optimisation  of  the  use  of  the 
hardware  resources. 

•  Fault  tolerance  is  achieved  by  means  of  system 
reconfigurability,  and  improves  system 
reliability. 

•  System  growth  and  the  ability  to  apply  the  system 
to  aircraft  for  a  wide  range  of  roles  are  supported 
by  the  use  of  an  open  system  architecture. 

•  Network  independence  is  provided  by  the  use  of 
the  Nil,  and  permits  the  upgrading  of  the  network 
technology. 

•  Software  technology  transparency  is  supported 
by  the  standardisation  of  the  APOS  interface  to 
the  operating  system  at  a  level  above  the 
underlying  COTS  operating  system. 

The  development  of  the  Mission  Management  System 
as  a  transitional  architecture  implementing  mission 
management  functions  should  achieve  a  major  step 
towards  the  implementation  of  IMA  systems,  and 
provide  valuable  experience  for  their  consequent 
implementation  and  certification.  In  accordance  with 
the  proposed  incremental  certification  approach,  the 
Mission  Management  System  is  open  to  progressive 
development  to  incorporate  further  aspects  of  the 
ASAAC  IMA  concepts,  so  supporting  the  eventual 
migration  to  a  true  IMA  system. 

In  conclusion,  it  is  hoped  that  development  of  systems 
based  on  transitional  architectures,  and  particularly 
the  Mission  Management  System  presented  in  this 
paper,  will  significantly  ease  the  introduction  of 
Integrated  Modular  Avionic  systems. 
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11  ABBREVIATIONS 

A/C  Aircraft 

APOS  Application  to  Operating  System  Interface 
Layer 

ARINC  Aeronautical  Radio  Inc. 

ASAAC  Allied  Standard  Avionics  Architecture 
Council 

ATR  Air  Transport  Racking 
BIT  Built-In  Test 
BSP  Board  Support  Package 
COTS  Commercial  Off-The  Shelf 
CU  Communications  Unit 
DPU  Data  Processing  Unit 
EUCLID  European  Co-operation  for  the  Long  Term 
in  Defence 


EC 

GP 

GPU 

GSM 

I/O 

IMA 

Mil  Std 

MMC 

MMS 

MMU 

MOS 

MOTS 

MSL 

Nil 

OpenGL 

OS 

OSL 

PCI 

PMC 

POSIX 

RM 

RTBP 

RTOS 

RTP 

SBC 

SM 

SMBP 

SMOS 

TC 

VME 


Fibre  Channel 
Graphics  Processor 
Graphics  Processing  Unit 
Generic  System  Management 
Input  /  Output 

Integrated  Modular  Avionics 
Military  Standard  (US) 

Mission  Management  Computer 
Mission  Management  System 
Mass  Memory  Unit 

MSL  to  Operating  System  Interface  Layer 

Military  Off-The-  Shelf 

Module  Support  Layer 

Network  Independent  Interface 

Open  Graphics  Language 

Operating  System 

Operating  System  Layer 

Peripheral  Component  Interconnect 

PCI  Mezzanine  Card 

Portable  Operating  System  Interface 

Resource  Manager 

Run-Time  Blueprints 

Real-Time  Operating  System 

Research  and  Technology  Programme 

Single  Board  Computer 

System  Manager 

System  Management  Blueprint  Interface 
System  Management  to  Operating  System 
Interface  Layer 
Transfer  Connection 
Versa  Module  Europe 
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Avionics  Architecture  Standards  as  an  Approach  to 
Obsolescence  Management. 


DJJibb,  J.B.Walker 
BAE  SYSTEMS 

Sensor  Systems  Division 
Ferry  Road,  Edinburgh 
EH5  2XS  Scotland 


1  Summary 

Obsolescence  management  techniques  can  be 
categorised  as  either  production  engineering  based 
techniques  that  attempt  to  control  an  existing  situation  or 
design  based  approaches  that  attempt  to  minimise  the 
initial  problem.  This  paper  addresses  system  architecture 
design  as  an  approach  to  obsolescence  management.  The 
work  of  the  ASAAC  programme  in  developing  open 
architecture  standards  designed  to  exhibit  a  high  level  of 
obsolescence  robustness  is  described.  Other  issues  that 
relate  to  the  financing  and  organisation  of  obsolescence 
management  are  also  discussed. 

2  The  nature  of  the  problem 

Component  obsolescence  increasingly  affects  our  ability 
to  maintain  military  avionics  in  service  or  even  to 
maintain  production  capability.  The  electronic 
component  industry  is  now  almost  entirely  driven  by  the 
computer,  commercial  telecom  and  consumer  electronics 
markets.  The  military  market  is  much  less  than  1%  of  the 
total  electronics  market  and  at  this  level  it  is  no  longer 
able  to  finance  the  high  technology  plants  and  processes 
that  are  the  needed  to  produce  specific  military  grade 
versions  of  state  of  the  art  commercial  components. 
Military  platform  lifetimes  of  30  to  40  years  are,  if 
anything,  tending  to  increase  and  already  are  an  order  of 
magnitude  higher  than  the  typical  commercial  processor 
chip  lifetime  of  some  2  to  3  years.  The  decline  of  the 
military  grade  component  market,  coupled  with  the  rapid 
pace  of  component  technology  development,  now 
requires  us  to  find  ways  of  using  commercial  quality  and 
commercial  temperature  range  components  in  military 
systems. 

The  ownership  of  the  obsolescence  problem  by  the 
whole  industry  and  customer  community  will  be 
increasingly  necessary.  The  basic  issue  of  obsolescence 
is  not  new.  Equipment  designers  have  been  faced  with 
the  problem  of  making  the  right  component  choice  for 
many  years  and  strategies  for  predicting  the  timing  of 
component  obsolescence,  and  limiting  its  impact,  are 
generally  well  developed  in  the  avionics  industry.  The 
fundamental  issue  is  an  economic  one  and  put  very 
simply  it  is  that  the  cost  of  maintaining  a  capability  is 
not  zero!  In  the  past  equipment  suppliers  have  been 
expected  to  maintain  a  supply  of  components  over  the 
life  of  a  platform.  Increasingly  the  rate  of  component 
obsolescence  is  preventing  this. 


The  Weapon  System  user  will  wish  to  maintain  platform 
effectiveness  in  response  to  changing  threats.  Indeed  it  is 
normal  for  the  end  user  to  want  to  enhance  the  Weapon 
System  through  the  incorporation  of  new  or  improved 
capabilities.  Such  Weapon  System  upgrades  can  provide 
an  ideal  opportunity  to  also  manage  obsolescence!  In  the 
past  Weapon  System  upgrades  were  based  on  the  mid¬ 
life  update  or  MLU.  However  in  today’s  more  stringent 
economic  climate,  evolutionary  upgrades  based  on  reuse 
of  the  existing  design,  especially  the  software 
application  designs,  make  more  economic  sense.  These 
incremental  updates  spread  the  cost  of  the  update 
programme  over  time  and  are  now  generally  favoured.  In 
some  cases  such  upgrades  can  actually  become  self¬ 
financing  especially  if  older  more  expensive  hardware 
can  be  replaced  with  fewer  items  that  conform  to  a 
newer,  more  capable  but  less  expensive  standard. 

The  funding  of  the  obsolescence  problem  will  require 
significant  changes  in  the  way  we  do  business.  In  the 
military  avionics  systems  of  the  future  most  of  the 
system  functionality,  and  in  consequence  the  major  part 
of  the  design  intellectual  effort,  will  be  resident  in  the 
software.  Indeed  the  concept  of  modular  avionics  is  to 
standardize  the  hardware  content,  and  with  increasing 
COTS  usage  the  hardware  will  come  to  represent 
relatively  low  value  in  procurement  terms.  However  the 
intellectual  effort  needed  to  create  the  overall  avionics 
system  is  likely  to  be  greater,  not  less  than  before.  To 
sustain  the  design  teams  needed  to  develop  and  maintain 
future  systems  it  is  necessary  that  the  major  deliverable, 
that  is  the  software,  should  attract  profit  levels  over  the 
life-cycle  which  are  comparable  in  value  to  those  which 
have  to  date  sustained  the  hardware  based  avionics 
industrial  competence.  Arguably  an  avionics  business 
based  solely  on  the  supply  of  boxes  will  not  be  viable  in 
the  long  term.  Instead  the  industry  must  evolve  towards 
capability  based  partnerships  with  emphasis  on 
maintenance  of  capability  on  the  one  hand  in  return  for 
maintenance  of  realistic  margins  through  the  supply  and 
updating  of  hardware  and  software  systems. 

Producing  systems  with  highly  interactive  functions  and 
less  tangible  boundaries  than  have  been  customary  calls 
for  close  cooperation  between  avionics  systems  suppliers 
and  the  overall  system  integrators  or  airframe 
manufacturers.  A  whole  new  project  structure  is 
required,  in  which  risks  can  be  shared  and  specialist 
knowledge  pooled  across  a  horizontal  organization  very 
different  to  the  pyramid  approach  used  today. 
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The  "integrated  product  team"  concept,  combined  with 
team-based  incentives  and  goals  is  one  method  of 
achieving  the  necessary  critical  mass  of  skilled  and 
motivated  design  intellect. 

3  Production  Engineering  approaches  to 
obsolescence  management 

The  basis  of  what  we  shall  call  the  production 
engineering  approach  to  obsolescence  management  is  to 
be  found  in  the  familiar  component  engineering  and 
purchasing  disciplines.  Specialist  Component  Engineers 
will  be  involved  in  the  initial  component  selection 
process  and  will  analyse  the  proposed  component  lists 
from  the  point  of  view  of  obsolescence  so  as  to  identify 
single  source  items  or  items  predicted  to  have  short 
commercial  availabilities.  For  these  items  a  stock 
holding  and  purchasing  plan  might  be  employed  based 
on  lifetime  buys,  or  alternatively  on  continuous 
monitoring  of  the  component  availability  together  with 
last  time  buys  as  and  when  necessary.  Increasingly  the 
Component  Engineer  will  be  supported  by  access  to 
industry  component  databases  and  in  the  case  of  a  large 
project  may  exchange  component  availability  data  with 
other  companies  also  involved  in  the  programme. 

Given  knowledge  of  the  exact  production  quantities  and 
time-scales  it  should  be  possible  to  guarantee  sufficient 
stock  is  held,  or  can  be  obtained,  to  meet  the  build  and 
life-time  support  requirements  with  minimum  (but  not 
zero)  financial  outlay.  Of  course  a  great  many 
circumstances  can  upset  this  ideal  situation  so  that  the 
stock  fails  to  match  the  production  build  and  support 
levels.  Increased  scrap  rates,  field  failures  or  simply 
additional  orders  can  all  become  problems.  Again 
ultimately  this  is  a  financial  issue  since  with  unlimited 
funds  sufficient  stocks  could  be  held  for  almost  any 
eventuality!  If  all  else  fails  the  final  resort  is  to  redesign 
the  affected  assembly  at  the  lowest  level  where 
interchangeability  can  be  achieved  so  as  to  minimise  any 
necessary  re -qualification  costs. 

This  paper  describes  a  complementary  approach  to 
obsolescence  management  concentrating  on  the  initial 
definition  of  the  system  architecture.  The  paper 
describes  the  work  of  the  ASAAC  programme  in 
developing  open  architecture  standards  designed  to 
exhibit  a  high  level  of  obsolescence  robustness. 

4  System  Architecture  as  an  Approach  to 
Obsolescence  Management 

One  of  the  ways  to  break  the  dependence  of  systems  on 
specific  COTS  technologies  is  to  design  systems  with  so 
called  Open  Architectures  that  provide  “loose”  coupling 
between  the  avionics  applications  and  the  underlying 
infrastructure  of  the  computing  platform.  This  “loose” 
coupling  requires  standardised  interfaces  between  the 
application  software  and  the  hardware,  system  software 
and  network  interconnects  so  as  to  provide  the  required 
software  portability.  In  addition  to  the  software 
interfaces  other  interfaces  are  required  to  provide 
technology  transparency  in  the  mechanical,  power 


distribution,  network  and  management  aspects  of  the 
system.  The  term  System  Architecture  refers  to  a 
consistent  set  of  such  interfaces  and  the  associated 
hardware  and  software  building  blocks.  By  carefully 
choosing  the  building  blocks  set  and  associated 
interfaces  it  is  possible  to  define  a  stable  avionics 
infrastructure  that  can  potentially  be  maintained  over  the 
life  of  a  platform.  The  design  of  these  interfaces  and 
building  blocks  is  the  main  objective  of  the  Allied 
Standard  Avionics  Architecture  programme  ASAAC. 
The  ASAAC  programme  was  originally  set  up  to  take 
benefit  from  the  life  cycle  cost  savings  and  enhanced 
performance  potential  of  Integrated  Modular  Avionics. 
Given  the  design  issues  that  are  raised  by  more 
integrated  systems,  the  desire  to  use  COTS  and  the 
required  long  platform  lifetime  it  is  no  surprise  that  the 
ASAAC  architecture  concepts  directly  result  in  a  system 
architecture  that  is  inherently  more  robust  with  respect  to 
component  obsolescence. 

5  ASAAC  Project 

The  ASAAC  Phase  II  Programme  is  sponsored  by  the 
MoDs  of  the  UK,  Germany  and  France  through  a  tri¬ 
lateral  Memorandum  of  Understanding  that  provides  for 
a  programme  to  define  a  set  of  STANAGs  for  military 
core  avionics.  The  first  draft  of  ASAAC  standards  was 
issued  in  February  1999  and  the  current  phase  of  work, 
which  began  in  December  1999,  is  a  45 -month 
programme  to  demonstrate  and  validate  the  standards. 
The  remainder  of  this  paper  describes  the  major  goals  of 
the  project  and  gives  an  overview  of  the  top-level 
requirements  derived  from  those  goals.  Each  architecture 
concept  area  comprising  software,  packaging,  networks 
and  system  management  is  described  together  with  a 
short  description  of  the  relevant  standards. 

5.1  ASAAC  Architecture  Goals 

The  prime  objective  of  ASAAC  is  to  define  a  flexible 
avionics  architecture  that  will  balance  affordability 
constraints  with  combat  capability  and  combat 
availability.  When  completed,  the  architecture  will  be 
captured  in  a  set  of  military  standards  (STANAGS)  for 
IMA  systems. 

The  three  principle  goals  for  ASAAC  are, 

•  Reduced  Life  Cycle  Cost 

A  major  objective  is  to  reduce  the  accumulated  costs 
over  the  life  cycle  of  a  system  i.e.  the  acquisition  and 
support  costs. 

•  Improved  Mission  Performance 

The  system  must  be  capable  of  fulfilling  the  missions 
asked  of  it  and  satisfy  all  possible  airborne  platforms  in 
terms  of  functionality,  capability,  accuracy, 
configurability  and  interoperability  under  the  full  scope 
of  operating  conditions. 

•  Improved  Operational  Performance 

The  goal  adopted  is  that  the  system  must  achieve  a 
combat  capability  of  150  hours  (equivalent  to  30  days) 
without  maintenance  with  an  availability  of  at  least  95%. 
This  goal  far  exceeds  that  achievable  today  and  an 
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ASAAC  system  will  be  required  to  exhibit  fault 
tolerance  so  that  it  can  survive  the  occurrence  of  faults 
with  a  required  level  of  functionality. 

In  addition,  the  maintenance  philosophy  dictates  that 
modules  of  the  system  must  be  interchangeable  between 
platforms  of  the  different  NATO  nations  and  replaceable 
at  first  line. 

5.2  Requirements 

ASAAC  has  established  a  set  of  top-level  requirements 
for  an  avionics  architecture  that  are  derived  from  the 
three  major  drivers  described  above.  The  required  output 
from  ASAAC  is  a  set  of  standards  for  military  avionics. 
To  define  those  standards,  ASAAC  first  defined  a  set  of 
concepts,  which  described  the  functionality  expected  of 
a  future  avionics  system,  covering  all  aspects  of  the 
system  from  software  through  to  packaging.  From  these 
concepts,  the  nature  and  specification  of  the  necessary 
interfaces  were  derived.  These  interfaces  include 
physical  standards,  software  interfaces  and  architectural 
descriptions. 

The  top-level  requirements  established  by  ASAAC  are 
as  follows: 

1.  Small  Set  of  Common  Modules 

The  set  of  common  modules  should  be  reduced  to  a 
minimum  to  reduce  development  and  support  costs. 

2.  Modules  Applicable  to  Wide  Range  of  Platforms 

The  architecture  should  be  able  to  support  the  needs  of  a 
wide  variety  of  airborne  platforms.  The  architecture 
must  therefore  be  scaleable  to  be  applicable  to  a  wide 
range  of  different  platforms. 

3.  Re-use  of  Software 

The  reusability  of  software  between  the  different 
computational  elements  should  be  maximised. 

4.  Modules  Replaceable  at  1®*  Line  on  Aircraft 

The  system  must  be  designed  such  that  the  modules  can 
be  removed  at  the  operational  site  for  replacement. 

5.  No  Base  and  Depot  Level  Maintenance 

The  combat  dependence  of  a  platform  on  fixed-site 
airbases  should  be  reduced  or  eliminated 

6.  Deferred  Maintenance/Fault  Tolerance 

The  architecture  shall  have  sufficient  fault  tolerance  to 
enable  the  system  to  be  restored,  to  a  predetermined 
level  of  capability,  in  the  event  of  a  fault  at  least  until  the 
next  scheduled  maintenance  event. 

7.  Comprehensive  BIT  and  Testability 

The  architecture  shall  not  require  tools  at  line  and 
shall  allow  on-aircraft  maintenance. 

8.  Interoperability 

Separate  elements  of  the  architecture  shall  inter-operate 
with  each  other. 

9.  Interchangeability 

This  requirement  relates  to  the  ability  to  interchange  any 
element  with  any  other  separately  developed  architecture 
element  of  the  same  generic  function. 


10.  Technology  Transparency 

The  architecture  should  not  rely  on  technology  specific 
implementation  techniques. 

11.  Use  of  Commercial  Components,  Technologies 
and  Processes 

The  architecture  should  be  designed  in  such  a  manner  as 
to  maximise  the  potential  use  of  commercially  available 
hardware  and  software  products. 

12.  Maximise  Digital  Processing  of  Functions 

The  architecture  should  support  the  maximum  amount  of 
digital  processing. 

13.  Functional  and  Physical  Integration 

It  should  be  possible  to  attain  a  high  level  of  functional 
integration  across  a  physically  integrated  platform.  This 
requirement  aims  to  promote  the  abstraction  of  software 
applications  from  hardware  in  order  to  allow 
applications  to  be  mapped  onto  various  hardware 
architectures. 

14.  Open  System  Architecture 

The  architecture  should  exploit  open  commercial 
standards  having  a  high-perceived  level  of  longevity. 

15.  Growth  Capability; 

The  ability  to  incorporate  growth  in  technology 
performance  and  application  requirements  over  the  life 
of  the  system. 

16.  Modularity  and  Configurability; 

The  ability  to  partition  a  system  into  separate  elements, 
each  of  which  is  individually  replaceable. 

In  addition  to  these  top-level  requirements,  a  number  of 
technical  requirements  were  specified  to  ensure  the 
usability  of  an  ASAAC  system.  These  requirements 
covered  areas  such  as  certification  and  qualification, 
security,  system  management  and  environmental 
requirements. 

5.3  ASAAC  Concept  Overview 

This  section  will  provide  an  overview  of  the  concepts 
and  standards  currently  under  definition.  It  is  possible, 
and,  in  fact,  highly  likely,  that  the  concepts  will  change 
during  the  programme  as  a  result  of  the  experience 
gained.  All  of  the  concepts  in  ASAAC  are  highly 
integrated  and  because  of  this  there  are  numerous 
dependencies  that  make  it  difficult  to  describe  the 
concepts  clearly  in  a  sequential  manner.  The  software 
concept  constitutes  the  most  important  area  within 
ASAAC  and  it  has  therefore  been  described  first,  the 
other  concepts  following  in  an  arbitrary  order. 
Throughout  the  text  there  are  several  references  to 
concepts  that  are  defined  in  more  detail  later  in  the 
paper. 

5.3.1  ASAAC  Software  Concept 

The  ASAAC  software  architecture  concept  defines  a 
three-layer  architecture,  based  on  the  philosophy  shown 
in  Figure  1.  This  philosophy  describes  three  layers, 

•  Application  Layer  (AL)  -  representing  the 
applications  that  are  specific  to  a  particular  aircraft 
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or  platform,  but  are  independent  of  the  enabling 
hardware. 

•  Operating  System  Layer  (OSL)  -  representing  the 
system  software  usable  across  all  aircraft  types  and 
on  all  hardware  architectures. 

•  Module  Support  Layer  (MSL)  -  representing  the 
hardware  specific  software  that  allows  the  upper 
software  layers  to  be  hardware  independent. 


Aircraft: 

Hardware: 


Aircraft: 

Hardware: 


Aircraft: 

Hardware: 


Dependent 

independent 


independent 

independent 


independent 

Dependent 


Figure  1  Software  Architecture  Philosophy 

This  philosophy  requires  the  definition  of  two  interfaces, 
as  shown  in  Figure  2  Software  luterfaces. 

These  are  the: 

•  APOS  -  the  Application  to  Operating  System 
interface  and  the 

•  MOS  -  the  Module  to  Operating  System  interface 

These  interfaces  provide  the  independence  for  each  of 
the  layers  described  previously.  In  addition  to  these 
layers,  three  functional  concepts  viz.  Generic  System 
Management,  Blueprints  and  Virtual  Channels  were 
defined. 


Application  Layer 


APOS 


Operating  System  Layer 
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Module  Support  Layer 


Figure  2  Software  luterfaces 
•  Geueric  System  Mauagemeut  Coucept 

The  system  management  of  an  IMA  system  can  be  split 
into  two  distinct  categories, 

•  Application  Management  and 

•  Run-time  System  Management. 


Applications  Management  involves,  for  example, 
mission  selection  and  controlling  the  moding  aspects  of 
a  system  i.e.  which  applications/processes  need  to  be 
active  during  a  given  phase  of  flight.  This  category  is 
implemented  by  the  Application  Manager  (AM) 
located  in  the  AL.  Run-time  System  Management  refers 
to  controlling  system  initialisation  and  shutdown, 
configuration  and  reconfiguration,  fault  management, 
interfacing  with  blueprints  and  application  scheduling. 
This  category  is  implemented  by  the  Generic  System 
Manager  (GSM)  located  in  the  OSL.  The  GSM 
comprises  four  functional  elements;  Health  Manager, 
Fault  Manager,  Configuration  Manager  and  Security 
Manager.  The  nature  and  operation  of  the  GSM  and 
these  elements  are  covered  in  more  detail  in  section 
5.3.4. 

•  Blueprint  Concept 

In  order  to  support  application  re-use  across  different 
hardware  technologies  and  architectures  the  concept  of 
Blueprints  configuration  files  has  been  defined. 
Blueprints  describe  the  mapping  between  the  resources 
required  by  an  application,  in  terms  of  processing  power 
and  communication  requirements,  to  the  available 
resources  provided  by  the  hardware.  They  are  realized  as 
a  database  directly  accessible  by  the  GSM.  Blueprints 
are  covered  in  more  detail  in  section  5.3. 1.1. 

The  final  software  architecture  incorporating  these 
concepts  is  shown  in  Figure  3.  The  Operating  System 
and  Extensions  block  includes  both  the  operating  system 
required  for  scheduling  and  task  prioritisation  purposes 
and  other  functional  elements  such  as  the  Virtual 
Channel  Manager  to  support  communications  within  the 
system. 

This  software  architecture  requires  the  definition  of  the 
following  interfaces, 

•  SMOS  -  the  System  Manager  to  Operating  System 
interface 

•  SMBP  -  the  System  Manager  to  Blueprints 
interface  and  the  following  logical  interfaces, 

•  OLI  -  the  Operating  System  Logical  Interface 

•  MLI  -  the  Module  Support  Layer  Logical  Interface 

•  GLI  -  the  GSM  Logical  Interface 

These  interfaces  are  described  in  more  detail  in  section 
5 .3 . 1 .2  Software  Interface  Definitions. 

•  Virtual  Channel  Concept 

Virtual  Channels  (VCs)  are  a  message-based  means  of 
communication  between  processes.  They  are  designed 
to  support  the  abstraction  of  application  communication 
from  hardware  implementation.  VCs  are  predictable  in 
operation.  In  other  words,  an  application  can  depend 
upon  a  VC  to  provide  a  certain  set  of  performance 
characteristics,  for  example  defined  latency  or 
bandwidth.  VCs  support  one-to-one  and  one-to-many 
communication  topologies.  Other  topologies,  such  as 
many-to-many,  can  be  implemented  using  these  two 
basic  mechanisms.  If  a  process  on  one  processor  needs 
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Figure  3  ASAAC  Software  Architecture 


to  communicate  with  a  different  process  on  the  same 
processor,  shown  as  type  I  in  Figure  4  Virtual  Channel 
Operation  the  communication  configuration  and  eventual 
message  handling  are  carried  out  by  the  Virtual  Channel 
Manager  (VCM)  resident  in  the  OSL.  For 
communication  between  processors  on  the  same  module 
and  on  different  modules,  shown  as  types  II  and  III 
respectively  in  Figure  4  Virtual  Channel  Operation,  a 
routing  service  within  the  MSL  must  assist  the  VCM  in 
ensuring  correct  transmission  of  the  data. 

5.3.1.1  Blueprints 

Blueprints  contain  the  information  that  defines  the 
mapping  of  application  processes  onto  the  functional 
modules.  In  order  to  operate,  the  system  will  require  a 
number  of  certified  functional  configurations.  A 


functional  configuration  in  this  context  refers  to  a 
mapping  of  application  processes  to  module  processors. 
These  configurations  will  be  specified  at  design-time  and 
verified  against  the  constraints  placed  on  the  system.  The 
set  of  allowable  configurations  will  be  stored  within  the 
system  and  referenced  at  run  time.  A  choice  between  the 
certified  configurations  will  be  made  depending  upon 
factors  such  as  fault  occurrence,  mission  status  etc.  In 
the  event  of  a  detected  and  localised  fault  or  a  mode 
change  request,  a  reconfiguration  will  be  performed  by 
first  selecting  and  then  instantiating  the  most  appropriate 
new  functional  configuration. 

5.3.1.2  Software  Interface  Definitions 

The  following  interfaces  are  defined  in  the  software 
concept: 


Figure  4  Virtual  Channel  Operation 
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•  APOS  -  Application  to  Operating  System 

This  interface  is  split  into  two  sections;  the  Core  APOS 
and  the  Specific  APOS.  The  Core  APOS  applies  to  all 
module  types,  whereas  the  Specific  APOS  contains 
services  specific  to  a  particular  module  type. 

At  present,  the  Core  APOS  contains  services  for  Virtual 
Channel  communication,  process  synchronisation,  timer 
handling,  fault  reporting,  application  management  and 
thread  management. 

The  Specific  APOS  contains  services  for  the  Graphics 
Processing  Module  (GPM),  Mass  Memory  Module 
(MMM)  and  Power  Conversion  Module  (PCM). 

•  MOS  -  Module  Support  Layer  to  Operating  System 
The  purpose  of  the  MOS  interface  is  to  isolate  the 
system  management  software  and  operating  system  from 
the  underlying  hardware.  It  is  envisaged  that  the  system 
management  software  and  operating  system  will  have  to 
be  certificated  and  that  it  will  be  impractical  to  have  to 
repeat  this  operation  every  time  the  hardware  changes. 
Compliance  with  the  MOS  standard  interface  will  allow 
for  reuse  of  the  System  Management  software  and  it  is 
expected  that  this  will  minimize  the  need  for 
rectification  of  the  system  management  software. 
However  it  is  also  recognized  by  ASAAC  that  COTS 
OSs  will  exist  that  do  not  comply  with  the  MOS.  To 
allow  these  COTS  products  to  be  exploited  in  situations 
where  it  is  not  essential  to  preserve  the  integrity  of  the 
system  management  software  ASAAC  allows  the  use  of 
the  MOS  to  be  optional. 

•  SMOS  -  System  Manager  to  Operating  System 

This  interface  allows  the  GSM  to  access  the  MOS 
services  for  network  configuration,  process  management, 
etc.  as  well  as  providing  standard  OS  services. 

•  SMBP  -  System  Manager  to  Blueprints  interface 

This  interface  allows  the  GSM  to  access  the  run-time 
Blueprints  in  order  to  manage  configuration  during 
system  operation. 

•  SMLI  -  System  Manager  Logical  Interface 

This  interface  allows  the  AM  to  specify  what  application 
configuration  is  required  and  notify  the  GSM  of  the 
reconfiguration  request. 

•  GLI  -  GSM  Logical  Interface 

This  interface  specifies  the  message  format  allowing 
GSMs  in  the  system  management  hierarchy  to 
communicate  with  each  other.  VCs  are  used  to  transfer 
the  messages. 

•  OLI  -  Operating  System  Logical  Interface 

This  interface  includes  specification  of  the  data 
presentation  format  to  allow  different  operating  systems 
to  communicate  with  each  other.  Standard  formats  are 
also  included  for  VCs  and  file  management. 

•  MLI  -  MSL  Logical  Interface 

This  interface  describes  the  network  protocol  and 
message  formatting  necessary  for  low-level 
communication. 


5.3.1.3  Software  Implementation 

Although  software  implementation  will  not  feature  in  the 
ASAAC  standards,  it  is  useful  to  give  an  overview  of  the 
implementation  methods  considered  in  the  definition  of 
the  standards.  A  significant  influence  on  the  choice  of 
software  implementation  in  ASAAC  is  that  of  module 
interchangeability.  This  requires  the  ability  to  remove 
one  module  and  replace  it  with  another  of  the  same 
generic  type  possibly  of  different  implementation 
technology  and  from  a  different  manufacturer.  At 
present,  it  is  expected  that  the  common  code  to  be 
executed  on  the  modules  within  an  ASAAC  system  will 
be  stored  in  a  central  location,  the  Mass  Memory 
Module  (MMM).  Therefore,  if  modules  are  to  be 
interchangeable,  one  of  the  following  software 
implementations  has  to  be  chosen, 

•  Produce  a  single  binary  image  for  every  processor 
on  every  module. 

•  Use  a  Virtual  Binary  Interface  (VBI).  This  is  a  run¬ 
time  interface  where  executable  code  can  expect 
certain  functions  to  be  resident  at  standardised 
locations  in  the  processor  memory  map. 

•  Use  an  interpreted  language  such  as  Java.  This 
would  provide  the  ultimate  in  portability  in  that  the 
code,  at  the  byte-code  level,  would  be  completely 
reusable  across  any  implementation  of  the  Java  (or 
other  language)  virtual  machine.  However, 
technology  in  this  area  is  in  its  infancy  and 
efficiency  is  not  considered  at  a  level  suitable  for 
avionics  systems. 

5.3.2  Common  Functional  Modules 

An  IMA  system  will  consist  of  racks  populated  by  Line 
Replaceable  Modules  (LRMs).  One  aim  of  ASAAC  is 
to  define  a  set  of  line  replaceable  Common  Functional 
Modules  (CFMs)  that  will  be  applicable  to  all  ASAAC 
compliant  IMA  systems.  Because  an  ASAAC  module  is 
line  replaceable,  it  must  have  well  defined  physical  and 
logical  boundaries.  ASAAC  is  tasked  with  defining  the 
interfaces  at  these  boundaries;  in  the  physical  sense,  it  is 
the  Module  Physical  Interface  (MPI),  and  in  the 
logical  sense,  it  is  the  Module  Logical  Interface  (MLI). 

ASAAC  does  not  standardise  on  the  architecture  or 
internal  interfaces  within  a  CFM.  ASAAC  instead 
specifies  two  major  areas  of  expected  functionality  for 
each  module  covering  processing-specific  and  system- 
level  functionality.  The  processing-specific  functionality 
is  covered  by  a  set  of  requirements  for  each  CFM  type. 
The  CFM  System  Support  standard  encompasses 
system-level  aspects  such  as  the  system  booting 
procedure,  PBIT  operation  and  OS  download. 

It  is  desirable  for  the  module  set  to  be  small  in  size  in 
order  to  maximise  the  potential  savings  in  life-cycle 
costs.  However,  the  task  of  standardising  different  types 
of  processing  and  functionality  is  not  simple;  abstraction 
of  the  complex  nature  of  modern  technologies  and 
dealing  with  differences  in  architectures  and  designs  is 
extremely  problematic. 

In  ASAAC,  six  different  CFM  types  have  been  defined. 
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Figure  5  AS  A  AC  Rack  Arrangement 


•  DPM  -  Data  Processing  Module 

The  DPM  covers  the  data-dependent  data  processing 
activities  expected  of  the  IMA  system. 

•  SPM  -  Signal  Processing  Module 

The  SPM  covers  the  data-independent  processing 
activities  of  the  IMA  system,  such  as  DSP  based  front- 
end  signal  processing. 

•  GPM  -  Graphics  Processing  Module 

The  GPM  provides  symbol-based  graphics  generation 
and  image  composition  and  formatting. 

•  MMM  -  Mass  Memory  Module 

ASAAC  promotes  the  use  of  a  central  facility  for 
program  storage  for  portable  code.  In  addition,  IMA 
systems  have  a  large  non-volatile  storage  requirement 
for  capabilities  such  as  terrain  information,  EW 
information,  mission  planning  etc. 

•  NSM  -  Network  Support  Module 

The  NSM  provides  the  network  upgradeability,  in  terms 
of  protocol  and/or  network  control,  by  locating  the  active 


components  for  the  network  within  a  line  replaceable 
module. 

•  PCM  -  Power  Couversiou  Module 

The  PCM  acts  as  the  first  stage  in  a  two-stage  power 
conversion  architecture  converting  raw  aircraft  power  to 
48V  for  distribution  across  an  avionics  rack  backplane. 
An  ASAAC  rack  (see  Fig  5)  is  expected  to  comprise; 

•  A  Siugle  NSM,  to  provide  the  network  routing, 

•  A  Siugle  MMM,  to  provide  initialisation  control 
and  program  download, 

•  Multiple  DPMs,  as  the  general  processing 
resource, 

•  Multiple  SPMs,  as  the  signal  processing 
resource, 

•  Oue  or  two  GPMs,  as  the  graphics  processing 
resource,  and 

•  Two  PCMs,  to  provide  dual  redundancy  on  the 
power  inputs. 
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Figure  6  Generic  CFM  Architecture 


16-8 


5.3.2.1  Generic  CFM  Concept 

The  DPM,  SPM,  GPM  and  MMM  module  types  outlined 
above  adhere  to  the  Generic  CFM  Concept  shown 
graphically  in  Figure  6  Generic  CFM  Architecture.  This 
concept  was  devised  to  promote  re-use  of  hardware  and 
software  elements  for  module  manufacturers.  The 
Generic  CFM  Concept  defines  the  following  functional 
units: 

•  MSU  -  Module  Support  Unit. 

The  MSU  is  responsible  for  supporting  certain  system 
activities,  specifically  System  Initialisation  and  Fault 
Management.  The  MSU  also  supports  generic 
functionality  required  of  each  ASAAC-visible  processor, 
i.e.  one  that  executes  the  ASAAC  software  stack,  such  as 
time  synchronisation  and  fault  logging.  The  MSU 
contains  a  programmable  resource,  termed  a  Module 
Controller.  Together  with  non-volatile  memory  used  for 
status,  BIT  and  fault  logging.  The  MSU  is  also 
responsible  for  standard  time  distribution,  which  is 
covered  in  more  detail  in  section  5.3.5. 

•  NIU  -  Network  Interface  Unit 

Each  module  will  interface  to  the  standard  ASAAC 
network  through  the  MPI  and  MLI.  Although  each 
module  type  will  likely  have  different  network  interface 
requirements,  in  terms  of  number  of  links  and  link 
capacity,  a  significant  amount  of  the  network  interface 
should  be  common  between  module  types  assuming  the 
same  network.  The  NIU  is  responsible  for  acting  as  the 
primary  network  interface  on  the  module  and  converts 
the  on-board  communications  to  the  format  required  by 


the  ASAAC  network.  The  present  network  concept  in 
ASAAC  refers  to  a  Packet-Switched  and  a  Circuit- 
Switched  network;  these  are  covered  further  in  section 
5.3.3. 

•  RU  -  Routing  Unit 

The  RU  represents  the  internal  communication  within  a 
CFM.  The  Routing  Unit  implies  no  architecture  or 
implementation;  it  only  describes  the  functional 
capability  that  allows  all  the  other  units  to  communicate 
with  each  other. 

•  PU  -  Processing  Unit 

The  PU  represents  the  processing  specific  functionality 
for  each  of  the  module  types;  data,  signal,  graphics 
processing  or  mass  memory. 

•  PSE  -  Power  Supply  Element 

48V  is  provided,  as  standard,  to  each  module  from  the 
backplane.  It  is  the  responsibility  of  the  PSE  to  convert 
this  input  to  the  voltage  levels  required  on  the  module. 
Each  CEM  will  have  dual-redundant  power  inputs  and 
the  PSE  shall  be  able  to  consolidate  these. 

5.3.3  Network 

The  networking  requirements  for  IMA  systems  differ 
greatly  from  those  of  previous  federated  systems.  The 
splitting  of  processing  functions  that  were  previously 
located  within  single  units  and  the  trend  to  higher 
digitisation  rates  give  rise  to  a  larger  required  total 
network  bandwidth.  In  addition,  the  requirements  that 
the  system  support  fault  tolerance  demands  that  the 
network  support  a  high  level  of  mobility  of  software 


Figure  7  ASAAC  Network  Architecture 
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application  functions  within  the  physical  system.  The 
top-level  requirement  for  module  interchangeability 
implies  that  the  communication  network  must  provide 
standardised  interfaces  and  operations.  At  the  same  time 
the  network  concept  must  support  technology 
transparency  and  provide  for  the  incorporation  of  COTS 
technology  with  potential  for  scalability  and  growth.  A 
unified  approach  to  the  network  for  the  whole  IMA 
system  is  desirable  in  order  to  avoid  the  proliferation  of 
hardware  and  software  elements  for  different  network 
types. 

Parallel  electrical  bus  technology  is  perceived  to  now  be 
at  an  upper  limit  as  far  as  the  module  interface  is 
concerned.  Serial  protocols  are  very  much  preferred 
because  of  their  routing  and  growth  capabilities  and 
because  of  the  predicted  transition  from  electrical  to 
optical  transmission  media.  Although  optical  media  for 
module  interconnection  has  still  to  be  proven  for 
extensive  use  in  an  avionics  environment,  especially  the 
choice  between  single-  and  multi-mode  technologies,  it 
is  almost  inevitable  that  it  will  be  fully  adopted  for  IMA 
systems  in  the  future.  ASAAC  has  made  the  use  of 
optical  media  mandatory  for  the  standards  demonstration 
and  validation  to  be  performed  as  part  of  the  project. 

The  current  baseline  for  the  network  describes  two 
distinct  network  components  viz. 

•  Circuit-switched  network  and 

•  Packet-switched  network 

These  two  networks  make  use  of  an  NSM  to  provide  the 
routing  and  link  reconfiguration. 

The  circuit-switched  network  is  implemented  using 
unidirectional  SDH  STM- 16  point-to-point  links.  This 
network  is  aimed  for  high-bandwidth  data-streaming 
applications.  The  particular  version  of  SDH  used,  STM- 
16,  should  provide  a  single  link  bandwidth  of  2.488 
Gbit/s.  The  NSM  will  contain  protocol-independent 
switches  to  provide  the  routing. 

The  packet-switched  network  will  be  implemented  using 
ATM  on  top  of  an  SDH  STM-4  physical  layer.  This 
network  is  aimed  at  the  lower  bandwidth  applications 
requiring  high  routing  flexibility.  SDH  STM-4  can  be 
expected  to  provide  a  bandwidth  of  622  Mbit/s.  The 
NSM  will  contain  the  ATM  switches  necessary  to 
provide  the  routing. 


The  interconnection  architecture  between  modules  using 
the  NSM  is  shown  in  Figure  7  ASAAC  Network 
Architecture  Each  module  communicates  via  packet- 
switched  and  circuit-switched  network  interfaces.  Any 
communication  from  an  application  is  directed  to  the 
relevant  interface  by  the  MSL  on  the  processor. 

The  standards  relevant  to  the  network  are  the 

•  MPI  -  the  module  physical  interface  to  the  network, 
and  the 

•  MLI  -  the  module  logical  interface  to  the  network. 

5.3.4  System  Management 

System  Management  builds  upon  the  other  concepts  to 
allow  an  IMA  system  to  operate.  In  ASAAC,  the 
System  Management  concept  does  not  relate  directly  to  a 
standard  however  elements  of  the  concept  are 
implemented  in  other  standards,  such  as  the  SMOS  and 
CFM  System  Support.  The  majority  of  the  concept  is 
defined  in  the  System  Management  Guidelines.  In 
essence,  the  concept  exists  as  a  recommended  method  of 
implementation  describing  sets  of  functionality  rather 
than  as  a  set  of  interface  standards. 

System  management  must  be  able  to  control  the 
configuration  and  operation  of  an  avionics  system  at 
processor  level,  and  at  the  higher  rack  or  integration  area 
levels.  To  achieve  this,  the  system  management  concept 
in  ASAAC  follows  a  hierarchical  approach,  maximising 
the  modularity  and  re-use  of  functional  elements.  The 
following  levels  of  hierarchy  are  defined, 

•  Aircraft  level 

•  Integration  Area  level 

•  Resource  Element  level 

Bi-directional  communication  exists  between  the  levels 
of  system  management  to  provide  control  and  reporting 
paths  that  allow  a  coherent  view  of  the  system.  The 
system  management  concept  is  implemented  by  the 
Generic  System  Manager  (GSM)  and  Application 
Manager  (AM)  in  the  software  concept.  The  GSM  is 
resident  within  the  OSL  of  the  software  stack  and  the 
AM  within  the  application  layer.  The  hierarchy  is 
shown  in  Figure  8  System  Management  Hierarchy. 


Figure  8  System  Management  Hierarchy 
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The  GSM  will  contain  the  following  functional 
elements, 

•  Health  Monitor  (HM)  -  This  element  is 
responsible  for  monitoring  the  health  of  the  system. 
It  receives  input  from  the  Fault  Manager  located  in 
the  next  level  down  in  the  management  hierarchy,  as 
shown  in  Figure  9  GSM  Interactions.  After 
processing  of  the  fault  reports,  it  will  indicate  to  the 
Fault  Manager  located  in  the  same  level  of  hierarchy 
if  the  HM  believes  a  persistent  fault  to  exist. 

•  Fault  Manager  (FM)  -  This  element  is  responsible 
for  collating  fault  reports  from  the  HM  and 
reporting  to  the  HM  in  the  management  layer  above. 
The  FM  then  determines  the  action  to  be  taken  and 
makes  a  request  for  reconfiguration  to  the 
Configuration  Manager.  The  nature  of  the  request  is 
dependent  upon  the  nature  of  the  fault  report. 

•  Configuration  Manager  (CM)  -  This  element  is 
responsible  for  co-ordinating  the  requested 
reconfigurations  from  the  FM.  The  CM  in  one  level 
communicates  with  the  CM  in  the  lower  level  to 
manage  the  reconfiguration. 

•  Security  Manager  (SM)  -  This  element  performs 
fairly  independently  of  the  other  elements  and  is 
responsible  for  control  of  access  rights  for  input  and 
output  requests  within  the  relevant  management 
area,  be  it  aircraft,  integration  area  or  resource 
element.  The  nature  of  security  in  an  IMA  system  is 
covered  later  in  this  section. 

A  resource  element  is  conceptually  defined  as  the  lowest 
level  of  the  management  hierarchy.  In  an  implemented 
system,  it  is  expected  that  each  processor  hosting  an 
ASAAC  software  stack  will  be  defined  as  a  Resource 
Element. 

For  aircraft  and  integration  area  managers,  a  GSM  on  a 
processor  or  resource  element  within  that  area  will  be 


nominated  as  the  area  manager.  This  nomination  occurs 
at  system  initialisation  or  if  necessary  after  a 
reconfiguration  resulting  from  a  failure. 

5.3.5  System  Time 

In  order  to  synchronise  the  management  tasks  and 
applications  within  the  system,  it  is  necessary  to 
maintain  an  absolute  time  clock  that  is  available  to  all 
elements  within  the  system.  To  achieve  this,  a  Master 
Reference  Clock  (MRC)  is  used  to  distribute  a  time 
signal  to  Reference  Clocks  located  on  the  modules. 

5.3.6  Reconfiguration 

The  reconfiguration  concept  refers  to  the  following 
definitions, 

•  Configuration  -  a  static  state  of  the  system,  with 
certain  processes  executing  on  certain  processors. 

•  Reconfiguration  -  the  set  of  actions  that  need  to  be 
executed  to  perform  a  transition  from  one 
configuration  to  another  configuration. 

There  are  two  distinct  situations  where  a  reconfiguration 
will  be  initiated. 

In  the  event  of  a  mode  change  request  -  here  the  task  is 
simple;  the  System  State  is  known  so  the  reconfiguration 
process  to  the  required  new  configuration  is  known. 

In  the  event  of  a  fault  -  here  the  situation  is  more 
complex.  If  a  fault  has  occurred,  then  the  system  is  in  an 
unknown  state.  This  state  must  be  analysed  and  verified 
before  reconfiguration  to  a  known  configuration  can  be 
carried  out.  The  present  concept  for  reconfiguration  is 
that  all  the  possible  (and  relevant)  configurations  of 
processes  on  processors  are  stored  in  the  blueprints. 
Upon  initialisation  or  reconfiguration,  the  most  suitable 
configuration  is  chosen  from  the  Blueprints. 

5.3.7  System  Initialisation 

The  initialisation  of  the  system  occurs  in  three  stages. 
First,  a  generic  procedure  is  executed  to  provide  a 
limited  initial  capability.  Second  a  mission  dependent 
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initialisation  configures  the  system  into  partial 
operational  mode  to  allow  activities  such  as  refueling 
and  maintenance.  Finally,  a  detailed  mission-oriented 
initialisation  configures  the  applications  to  provide  the 
full  avionics  functions.  These  initialisations  are 
essentially  a  sequence  of  reconfigurations  that  build  up 
levels  of  functionality  at  each  step.  The  present  concept 
is  to  utilise  a  MMM  as  a  ‘bootstrap’  module  to  initiate 
this  process  in  collaboration  with  a  DPM  and  an  NSM. 

5.3.8  Fault  Management 

Fault  Management  is  the  methodology  of  handling  faults 
within  a  system  in  order  to  prevent  total  or  partial  system 
failure.  It  encompasses  the  following  aspects, 

•  Fault  Tolerance  (FT),  which  allows  continued 
operation  of  the  system  in  the  presence  of  faults 

•  Integrated  Test  and  Maintenance  (ITM),  which 
allows  identification  of  the  failed  component  for 
repair. 

FT  has  the  further  responsibility  to  ensure  survival  of  the 
system  with  a  suitable  level  of  functionality  in  the  event 
of  a  fault. 

5.3.9  Security 

In  general,  security  is  concerned  with  the  protection  of 
assets  from  threats  where  a  threat  is  defined  as  the 
potential  for  abuse  of  the  protected  assets.  Because  of 
the  highly  integrated  nature  of  an  IMA  system, 
functional  areas  with  very  strict  security  requirements 
such  as  communications  and  navigation  are  brought  into 
close  contact  with  other  areas  such  as  radar  and  vehicle 
management.  IMA  systems  must,  therefore,  be  able  to 
deal  with  differing  security  requirements  across  common 
equipment  and  ensure  sufficient  asset  protection.  There 
are  two  major  areas  of  security, 

•  Communications  Security  (COMSEC)  -  for 

COMSEC,  a  functional  interface  to  a  cryptographic 
functionality  will  be  defined 

•  Computer  Security  (COMPUSEC)  -  for 

COMPUSEC,  the  functionality  can  be  located  either 
wholly  in  software  or  spread  between  hardware  and 
software. 

It  is  highly  likely  that  compliance  with  the  Common 
Criteria  (CC)  for  Information  Technology  Security 
Evaluation  will  form  part  of  the  accreditation  for  an  IMA 
system. 

5.3.10  Safety  and  Certification 

The  key  characteristics  that  an  ASAAC  system  must 
demonstrate  to  support  safety  certification  are  data 
integrity,  guaranteed  availability  of  data  and  resources, 
and  predictability  of  operation.  The  higher  integration 
that  is  achieved  through  the  use  of  IMA  will  mean  that 
safety/certification  issues,  similar  to  security  issues,  will 
begin  to  affect  a  larger  number  of  functional  areas. 

At  this  stage  of  the  ASAAC  project,  the  issues  regarding 
security  and  safety  and  certification  are  not  fully  defined. 
Task  forces  are  at  present  continuing  to  investigate  the 
possible  consequences  that  the  various  requirements  will 


have  on  an  IMA  system  and  have  yet  to  produce  an 
agreed  approach  for  recommendation. 

5.3.11  Packaging 

The  physical  outline  and  connector  configuration  of  a 
module  could  be  considered  one  of  the  most  important 
aspects  of  an  IMA  system.  Eor  modules  to  be 
interchangeable  at  all  there  must  be  a  standard  physical 
interface.  The  ASAAC  packaging  concept  defines  the 
Module  Physical  Interface  (MPI),  which  covers  the 
packaging,  cooling,  power  supply  distribution, 
electromagnetic  compatibility  and  interconnection 
standards. 

5.3.11.1  Module  Packaging 

The  ASAAC  packaging  baseline  standard  specifies  a 
module  format  similar  to  Double  Eurocard,  termed 
ASAAC  A.  However,  ASAAC  A  specifies  a  short-side 
connector  as  opposed  to  the  long  side  for  traditional 
VME.  Where  compatibility  could  be  considered  is  in  the 
usable  area  of  a  module.  In  that  case,  COTS  board 
designs  could  be  ported  to  the  standard  physical  outline 
with  greater  likelihood  of  success.  Because  of  the 
concept  defined  for  the  CEMs  in  ASAAC,  there  will  be  a 
minimum  area  suitable  for  providing  the  defined 
functionality.  Also,  the  fact  that  CEMs  are  to  be  line 
replaceable  implies  that  they  should  be  of  a  certain 
manageable  size.  It  is  generally  felt  that  Double 
Eurocard  is  approximately  the  correct  area  in  which  to 
provide  a  CEM  with  a  significant  capability. 

5.3.11.2  Module  Cooling 

Two  cooling  techniques  have  been  chosen  for  the 
present  baseline, 

•  Conduction  cooling,  with  the  possibility  to  use  heat 
pipes  in  the  module  core  to  enhance  the 
performance. 

•  Airflow  cooling,  with  air  circulating  either  outside 
the  CEM  (air  flow  around),  through  a  central  CEM 
heat  exchanger  (air  flow  through),  or  with  air 
directly  on  the  module  components  (direct  air  flow). 

These  options  are  chosen  to  provide  the  widest  range  of 
alternatives  between  affordability  and  performance,  thus 
catering  for  anticipated  module  power  dissipation  levels 
and  different  platform  cooling  systems. 

•  Module  Interconnect 

ASAAC  only  allows  optical  interconnections  external  to 
a  module,  except  for  power  distribution.  Eor  optical 
interconnect,  two  technologies  have  been  considered, 

•  Embedded  Fibre  -  the  optical  fibre  is  placed 
onto  an  adhesive  coated  substrate  and  an 
additional  protective  layer  mounted  on  top. 
Complex  topologies  are  possible,  including  star 
couplers. 

•  Polymer  -  this  technology  is  the  fabrication  of 
flexible  flat  sheets  of  polymer  containing  optical 
waveguides,  which  can  be  very  cost-efficient  if 
produced  in  large  quantities. 
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Figure  10  Power  Supply  Architecture 


•  Module  Connector 

ASAAC  will  define  a  connector  shell  capable  of 
accommodating  either  butt  coupled  or  free-space  inserts. 
The  connector  shell  consists  of  aluminium  support 
shells,  each  shell  having  three  main  cavities.  At  each  end 
of  the  module  shell  a  polarised  guide  pin  is  positioned 
with  the  corresponding  guide  socket  on  the  backplane 
shell.  Each  shell  cavity  can  accommodate  a  variety  of 
inserts;  standard  size  22  signal  contacts,  high  density 
PCB  signal  contacts,  size  16  power  contacts  and  32  or  48 
fibre-optic  contacts,  depending  on  density.  Therefore,  a 
customisable  connector  can  be  manufactured  that  is 
tailored  to  specific  system  requirements. 

5.3.12  Power  Distribution  Architecture 

The  power  distribution  architecture  within  ASAAC  is  a 
two-stage  conversion  process,  with  conversion  from  the 
aircraft  platform  supply  to  an  intermediate  internal  rack 
voltage  level,  and  subsequent  conversion  to  logic  voltage 
level  at  each  module.  A  Line  Replaceable  Chamber 
(LRC)  converts  the  aircraft  platform  supply  to  270VDC 
and  performs  the  supply  filtering.  The  Power  Conversion 
Module  (PCM)  converts  the  270VDC  supply  to  a  rack 
standard  of  48VDC.  This  scheme  is  shown  in  Figure  10 
Power  Supply  Architecture. 

48VDC  was  chosen  because  it  is  a  common  commercial 
standard  and  possesses  inherent  safety  and  support  for 
hot  plugging  and  unplugging  of  modules.  Note  that,  in 
the  architecture,  each  processing  module  has  dual 
redundant  supplies  to  enhance  fault  tolerance.  Each 
processing  module  will  perform  on-board  supply 
consolidation  and  conversion  to  appropriate  logic  levels. 

The  PCM  will  possess  load  current-monitoring 
capabilities  in  order  to  detect  faulty  power  circuits  on 
modules. 

5.4  Standards  Under  Definition 

The  standards  under  definition  by  ASAAC  are  listed  in 
Table  1. 


Standard  Name 

Status 

APOS 

First  draft  available 

MOS 

First  draft  available 

SMOS 

First  draft  available 

SMBP 

First  draft  available 

GLl 

First  draft  available 

OLl 

First  draft  available 

MLl 

First  draft  available 

CFM 

First  draft  available 

System  Support 

MPl 

First  draft  available 

Table  1  List  of  ASAAC  Standards 
6  Conclusions 

This  paper  has  described  the  ASAAC  Avionics 
Architecture  that  is  being  developed  to  provide  the 
technical  basis  for  advanced  avionics  for  new  platforms 
and  updates  from  around  2003  onward.  A  carefully 
designed  System  Architecture  can  provide  a  stable 
structure  within  which  COTS  components  and  processes 
can  be  accommodated  with  reduced  risk  from 
obsolescence.  The  interfaces  reduce  the  coupling 
between  the  application  software,  which  is  the  major 
repository  of  value  in  the  avionics  system  and  the 
underlying  hardware,  software  and  network  components. 
A  system  designed  around  IMA  concepts  will  be  much 
easier  to  upgrade  and  consequently  more  resilient  to 
component  obsolescence.  Maintaining  the  capability  of 
an  avionics  system  in  the  future  will  entail  regular 
expenditure  on  technology  insertion  activities  that  will 
provide  benefits  in  terms  of  performance  and  at  the  same 
time  will  contribute  to  the  management  of  component 
obsolescence. 
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Resume 

Les  applications  militaires  ayant  perdu  leur  leadership 
dans  le  domaine  de  felectronique,  elles  auront  de  plus  en 
plus  a  utiliser  des  technologies  civiles.  11  faudra 
apprendre  a  les  utiliser  ou  a  les  adapter  a  nos  specificites, 
par  exemple  faibles  volumes  en  production,  temperature 
de  fonctionnement  elevee...  L’ utilisation  de  ce  que  Ton 
a  pris  I’habitude  d’appeler  «  composants  sur  etagere  » 
continuera  meme  si  F  assurance  de  pouvoir  les 
approvisionner  sur  le  long  terme  est  un  souci  non 
negligeable. 

Mais  une  autre  technologie,  egalement  issue  du  Civil, 
parait  prometteuse  :  Les  «  System  on  Chip  »  ou  «  SoC  ». 
En  d’autres  termes,  la  possibilite  d’integrer  dans  un  seul 
circuit  ou  des  circuits  en  nombre  reduit  un  calculateur 
complet,  repondant,  par  exemple,  a  une  application  de 
pilotage  /  guidage  pour  missile.  Cette  approche  est 
maintenant  bien  etablie  dans  le  monde  civil  et  industriel 
tel  que  les  telecommunications,  mais  encore  relativement 
peu  implementee  dans  les  systemes  de  defense. 

11  s’agit  en  fait  d’une  technologie  ASIC  (Application 
Specific  Integrated  Circuit),  mais  integrant  jusqu’a 
plusieurs  millions  de  portes.  Pour  pouvoir  maitriser  la 
complexite  de  la  phase  de  conception  en  terme  de  cout  et 
de  delais,  les  SoC  sont  largement  bases  sur  la  notion  de 
reutilisation  de  blocs  fonctionnels :  les  « Intellectual 
Properties »  ou  « IP ».  En  fait,  ces  IP  ne  sont  rien 
d’autres  que  des  composants  sur  etagere  mais  virtuels, 
done  independants  d’une  quelconque  technologie.  11s 
peuvent  soit  achetes  soit  etre  issus  de  conceptions 
precedentes.  Les  avantages  sont  nombreux,  par  exemple  : 

•  11  est  possible  de  concevoir  le  SoC  sur  la  gamme  de 
temperature  voulue. 

•  En  cas  d’obsolescence  d’une  technologie,  la  societe 
utilisatrice  etant  proprietaire  de  la  definition  du 
circuit  peut  migrer  vers  une  technologie  plus 
recente... 


Certaines  difficultes  restent,  bien  entendu,  a  surmonter 
tel  que,  et  de  maniere  non  exhaustive  : 

•  L’acces  aux  fonderies,  en  cas  de  selection  d’une 
technologies  ASIC  (par  opposition  a  des 
Programmable  Logic  Devices  :  PLD)  du  fait  des 
faibles  volumes  ; 

•  La  duree  des  plannings  de  developpement ; 

•  Le  cout  des  composants  virtuels. 

Tous  ces  points  sont  passes  en  revue  dans  ce  document. 


Introduction 

L ’evolution  des  marches  Militaires 

L’ utilisation  de  concepts  civils  pour  des  applications 
militaires  est  une  tendance  qui  peut  deja  etre  constatee  et 
qui  va  surement  s’ amplifier.  Une  telle  demarche  n’est 
bien  sur  pas  sans  consequences.  L’une  d’elle  -  tres 
positive  -  consiste  a  ecrire  des  Specifications  Techniques 
de  Besoin  souvent  mieux  dimensionnees  par  rapport  aux 
besoins  reels.  Toutefois,  certaines  contraintes 
perdureront  comme  le  besoin  de  pouvoir  fonctionner 
dans  des  environnements  difficiles.  11  n’y  a,  en  effet, 
aucune  raison  que  les  profils  et  theatres  d’ operation  des 
missions  militaires  changent.  L’ elevation  de  temperature 
peut  aussi  etre  due  a  un  echauffement  cinetique 
(exemple  :  un  missile  en  vol  fibre).  Meme  si  on  peut 
s’attendre  a  des  progres  dans  la  gestion  des  calories,  cela 
ne  changera  probablement  pas  radicalement  le  probleme 
au  niveau  des  composants  electroniques. 

11  faut  noter  F  impact  que  peut  avoir  la  permanente 
diminution  des  lithographies,  diminution  qui  peut 
engendrer  d’autres  phenomenes  (SEU :  Single  Event 
Upset). 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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L ’utilisation  de  concepts  civils 

Le  sujet  peut  etre  aborde  sous  deux  aspects. 

Choix  de  standards  /  protocoles  et  d’elements 
d’architecture  de  systemes  et  de  calculateurs  civils  : 

C’est  le  1'"  aspect.  Pendant  la  tache  d’architecture,  un 
concepteur  peut  ainsi  selectionner  un  ou  plusieurs 
standard(s)  (exemples :  USB,  IEEE  1394,  PCI...).  II 
beneficiera  ainsi  du  support  de  la  tres  large  communaute 
utilisatrice :  existence  de  la  norme,  des  outils,  des 
composants  (virtuels  et  reels,  attention  au  risque  de 
perennite  pour  ces  derniers)...  Meme  s’il  decide  de 
n’utiliser  qu’une  partie  de  ce  dont  il  peut  disposer,  il  sera 
largement  gagnant  en  terme  de  temps  (et  done  de  cout) 
de  developpement  au  moins.  Ceci  dit,  il  faut  se  prevenir 
de  I’idee  consistant  a  considerer  que,  parce  que  la  norme 
existe  et  decrit  un  protocole,  tout  le  monde  -  y  compris 
les  neophytes  -  pourront  prendre  en  charge  une 
conception.  Les  protocoles  sont  complexes  et  une  simple 
lecture  meme  approfondie  d’un  document  outre  qu’elle 
est  franchement  rebarbative  est  loin  de  remplacer 
r  experience. 

En  tout  etat  de  cause,  il  s’agit  d’une  demarche 
extremement  positive  qu’il  faut  encourager.  Le  risque 
essentiel  est  de  selectionner  un  standard  devenant 
obsolete  rapidement,  risque  limite  si  un  minimum  de  soin 
est  apporte  lors  du  choix. 

Utiliser  des  composants  issus  du  monde  civil :  Il  s’agit 
du  2'™'’  aspect.  La  tache  n’est  pas  si  aisee  qu’il  y  parait. 

Le  probleme  de  la  gamme  de  temperature :  Il  est 
necessaire  de  prevoir  la  mise  en  oeuvre  de  ces 
composants  sur  une  gamme  de  temperature  elargie. 
Accessible  pour  des  composants  simples  (transistors)  ou 
a  structure  reguliere  (memoires),  I’exercice  se  complique 
notablement  pour  des  circuits  complexes  tels  que  des 
processeurs.  Ces  derniers  peuvent,  par  exemple, 
comporter  des  structures  en  partie  asynchrones  visant  a 
optimiser  les  performances  mais  qui  ne  sont  validees  par 
le  fournisseur  que  sur  la  gamme  de  temperature 
specifiee.  En  cas  d’ utilisation  sur  une  gamme  elargie,  il  y 
a  alors  des  risques  de  conflits  internes  lies  a  des  temps  de 
propagation  tangents  (courses  de  chemin).  On  constate 
des  comportements  aleatoires  sur  une  ou  plusieurs 
plage(s)  de  temperature  plus  ou  moins  reduite(s). 

Par  ailleurs,  I’idee  consistant  a  dire  que  «  nos  besoins 
etant  proches  de  ceux  de  1’ automobile,  nous  aurons  la 
une  source  d’approvisionnement  nous  convenant » 
pourrait  bien  de  se  reveler  fausse.  En  effet,  s’il  est  vrai 
que  les  contraintes  sont  similaires,  il  est  plus  que 
probable  que  I’industrie  automobile  va  s’orienter  vers  la 
conception  de  SoC,  done  de  circuits  dedies  inaptes  a 
remplir  nos  fonctionnalites. 

Le  probleme  de  la  perennite  :  Les  cycles  des  composants 
utilises  pour  des  applications  civils  sont  sans  commune 
mesure  avec  les  besoins  des  militaires.  Il  ne  s’agit  meme 


plus  de  risques  mais  d’un  element  a  considerer  de  base  : 
Il  faudra  faire  evoluer  la  definition  de  tout  equipement 
militaire  tout  au  long  de  sa  duree  de  vie  pour  traiter  les 
problemes  d’ obsolescence.  Le  cas  le  plus  simple  est 
lorsqu’il  suffit  de  remplacer  un  circuit  par  un  autre  de 
fonctionnalite  equivalente.  Exemple  type  :  les  memoires, 
pour  peu  que  la  carte  ait  ete  con9ue  de  maniere  a  pouvoir 
cabler  des  circuits  de  capacite  plus  importante.  L’ autre 
situation  extreme,  beaucoup  plus  difficile,  est  lorsque 
qu’il  n’est  plus  possible  de  trouver  un  composant 
equivalent.  Dans  ce  cas,  il  faut  au  moins  prevoir  une 
reprise  de  la  carte  et  des  couches  basses  du  logiciel. 

Disponibilite  des  composants :  Certains  composants, 
essentiellement  dedies  aux  applications  Telecom,  ou 
Automobile  par  exemple,  risquent  de  ne  plus  exister 
sous  leur  forme  classique  mais  uniquement  virtuelle. 

Information  des  fournisseurs  :  Bien  entendu,  dans  tons 
les  cas  de  figure,  les  fournisseurs  restent  plutot  avares  en 
information.  Nous  serous  done  tenu  au  courant  des 
disparitions  de  composants  de  maniere  parcellaire  et 
quant  a  obtenir  des  donnees  detaillees  sur  ce  qu’il  est 
necessaire  de  tester  et  comment  pour  envisager  d’ utiliser 
des  circuits  sur  une  gamme  de  temperature  etendue,  la 
c’est  du  domaine  du  reve.  Non  seulement,  ils  n’y  out 
aucun  interet  financier,  mais  en  plus  ils  ne  voudront 
surement  pas  s’ engager  a  nous  fournir  des  informations 
et,  en  plus,  a  les  tenir  a  jour  en  cas  d’evolutions. 

Une  solution  alternative  :  Le  «  System 
On  Chip  >> 

Devant  un  tableau,  il  faut  bien  le  dire,  un  peu  noir, 
comment  pouvons  nous  reagir.  Il  y  a  probablement 
plusieurs  possibilites,  mais  dans  ce  papier,  nous  nous 
contenterons  d’en  aborder  une :  Les  « Systems  On 
Chip  »  ou  «  SoC  ». 

Definition 

Depuis  deja  plusieurs  annees,  les  progres  des 
lithographies  sont  impressionnants  et  permettent 
d’integrer  dans  un  seul  circuit  plusieurs  millions  de 
portes.  Cela  a  permis  de  developper  des  processeurs 
puissants,  mais  ceux  ci  ne  representent  finalement 
«  que  »  le  marche  des  PC  et  des  stations  de  travail.  Il  y  a 
bien  d’autres  applications  industrielles  ou  grand  public 
qui  peuvent  beneficier  de  ces  possibilites  et  sont  a 
I’origine  meme  du  concept  de  System  On  Chip. 

Un  SoC  est  un  circuit  dedie,  integrant  sinon  toutes,  du 
moins  les  principales  fonctions  d’un  calculateur.  Elies 
sont  relatives  a  chaque  application,  mais  on  retrouve 
typiquement : 

•  1  ou  plusieurs  coeur(s)  de  processeur 

•  1  ou  plusieurs  coeur(s)  de  DSP  (Digital  Signal 
Processing) 
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•  des  peripheriques  : 

des  interfaces  bus  systeme  (ARINC,  MIL- 
STD-1553...) 

des  gestionnaires  de  liaisons  series 

des  ports  paralleles 

des  timers  /  horloges  temps  reel 

des  controleurs  de  commande  moteur 

(generateurs  PWM) 

•  et  bien  entendu  -  ce  serait  dommage  de  tie  pas  en 
profiter  -  des  blocs  de  logique  dediee. 

La  figure  1  propose  un  synoptique  generique  d’un  SoC. 
On  retrouve  finalement  des  notions  proches  de  celle 


d’une  structure  de  calculateur  classique,  avec  des  blocs 
fonctionnels  connectes  a  un  bus  on-chip.  Pour  ce  dernier, 
il  n’est,  malgre  tout,  pas  facilement  imaginable  de 
reprendre  des  standards  classiques  tel  que,  par  exemple 
un  bus  PCI.  En  effet,  certaines  contraintes  liees  a  la 
technologie  sont  a  considerer  (exemple  :  eviter  d’ avoir 
des  potentiels  flottants  en  interne  circuit,  done  par  de 
lignes  3  etats...).  Toutefois,  des  standards  apparaissent. 
II  convient  de  noter  les  efforts  sur  ce  sujet  d’organismes 
tel  que  VSIA  (Virtual  Chip  Interface  Alliance). 

II  est  aussi  possible  de  prevoir  des  blocs  analogiques 
ainsi  que  des  convertisseurs  analogiques  /  numeriques  et 
inversement. 


Liens  de  debug  (JTAG) 


Bus  on-chip  peripherique 


E/S 


E/S 


Memo  ires 
externes 


Bus  on-chip  haute  performances  calculateur 


Figure  1  :  Synoptique  generique  d’un  SoC 


Les  marches 

Le  principal  marche  a  I’origine  de  cette  tendance  est 
indubitablement  celui  des  telecommunications  qui  allie  a 
la  fois  : 

•  un  fort  besoin  d’ integration  pour  repondre  aux 
attentes  des  consommateurs  quant  au  poids  et  a 
Pautonomie  des  telephones  portables 

•  mais  aussi  de  gros  volumes,  ce  dont  se  felicitent  les 
fondeurs. 

D’autres  applications  apparaissent,  tels  que  les 
equipements  audio  /  video  et  F  automobile. 

L’ ensemble  des  marches  cites  est  caracterise  par  de  gros 
volumes  en  production  associes  a  des  couts  tres  faibles. 

Ce  qui  est  aussi  certain,  e’est  qu’on  ne  voit  aucun  signe 
laissant  penser  a  une  inversion  de  tendance.  C’est  plutot 
le  contraire,  il  est  probable  que  Ton  verra  apparaitre  de 
nouveaux  debouches  dans  les  domaines  industriels  et 
surtout  grand  public. 

Les  grands  foumisseurs  (d’outils  entre  autres  mais  pas 
exclusivement)  Ton  bien  compris  :  Il  suffit  de  faire  un 


passage  sur  les  sites  web  respectifs  ou  d’assister  a 
quelques  conferences  pour  en  etre  convaincu.  Tout 
tourne  autour  du  SoC,  a  un  point  tel  qu’il  vaut  mieux  etre 
un  peu  mefiant  vis  a  vis  de  ce  qui  s’en  reclame. . . 

Il  en  est  de  meme  au  niveau  de  la  presse  :  Il  n’est  pas  une 
seule  publication  qui  n’ait  pas  son  lot  de  references  au 
SoC  ! 

Il  ne  s’agit  done  pas  simplement  d’un  effet  de  mode, 
mais  d’une  tendance  bien  reelle  et  durable. 

Quelques  definitions  complementaires 

Avant  d  ‘aller  plus  loin,  il  est  necessaire  de  preciser 
certaines  definitions. 

Les  circuits  dedies.  Par  circuits  dedies,  on  entend  ASIC 
(Application  Specific  Integrated  Circuit)  ou  FPGA  (Field 
Programmable  Gate  Array). 

Le  synoptique  ci  dessous  (figure  2)  resume  les 
principales  etapes  d’un  developpement  type  pour  ces 
circuits.  Alors  qu’il  apparait  lineaire,  il  ne  Test  pas  dans 
la  realite.  Par  exemple,  il  est  certain  qu’il  y  a  un 
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rebouclage  entre  les  phases  «  Faisabilite  »,  «  STB  »  et 
«  Architecture  ».  De  meme,  si  un  probleme  est  decouvert 
durant  une  phase  de  verification,  il  y  a  correction,  celle  ci 
devant  etre  effectuee  generalement  dans  I’etape 
precedente  on  encore  avant.  Par  exemple,  un  probleme 
decouvert  en  Verification  «  2  »  pent  devoir  etre  corrige 
en  retournant  a  I’etape  de  « Modelisation ».  Enfin 
certaines  taches  n’ont  pas  ete  mentionnees  pour  ne  pas 
surcharger  le  synoptique.  Elies  n’en  sont  pas  moins 
importantes.  II  s’agit  de  1’ insertion  de  dispositifs  de  test 
ou  encore  du  floorplan  (ou  pre-placement,  indispensable 
pour  preparer  le  routage  et  eviter  des  problemes  lors  de 
I’etape  de  Verification  «  3  »). 


Sous  forme  textuelle  et,  mieux, 
accompagnee  de  langage  C  au  moins 
pour  Talgorithmie. 


Tache  fondamentale  pour  laquelle  il 
faut  accepter  de  passer  du  temps,  meme 
si  on  donne  I’impression  de  ne  pas 
avancer. 

Transcription  de  la  STB  en  description 
simulable.  Utilisation  des  langages 
HDL:  VHDL  ou  Verilog. 


Simulation. 


Transformation  du  modele  en  schema 
electrique  (SE). 


Simulation.,  analyse  de  timing. 


Dessin  des  equipotentielles  a  partir  du 
SE  en  respectant  les  isolations. 


Simulation.,  analyse  de  timing. 


Realisation  des  masques  et  du  silicium. 
On  croise  les  doigt! 


Figure  2  :  Flat  de  conception  d’un  circuit personnalise 


I’exclusivite).  Les  IP  peuvent  etre  definies  comme  des 
composants  virtuels.  Il  s’agit  done  de  blocs  fonctionnels 
qui  peuvent  etre  achetes.  Le  marche  est  particulierement 
actif  et  I’offre  tres  fournie.  On  trouve  la  plupart  des 
fonctions  listees  au  §  «  Definition  du  SoC  ».  Il  est  aussi 
possible  de  les  developper  en  interne  societe.  Elies 
correspondent  alors  a  des  fonctions  tres  specifiques  a 
I’activite  et  que  Ton  souhaite  pouvoir  reutiliser  dans 
plusieurs  applications. 

Il  est  interessant  de  rentrer  un  peu  plus  dans  le  detail, 
sachant  que  la  maitrise  sur  le  long  terme  d’un  SoC  (ou  de 
n’importe  quel  circuit  mettant  en  oeuvre  un  IP)  est 
fonction  du  type  d’lP  utilise  (ou  instancie).  On 
distingue  : 

•  Les  Soft  IP  :  Les  blocs  fonctionnels  sont  decrits  en 
langage  HDL  et  sont  accompagnes  de  testbenches  et 
de  directives  de  synthese  logique.  Celle  solution 
permet  de  maitriser  entierement  le  modele  du  SoC  et 
assure  une  bonne  perennite  a  long  terme.  Par  contre, 
elle  demande  un  peu  plus  de  travail  lors  de  la  phase 
de  developpement. 

•  Les  Firm  IP  ;  Les  blocs  fonctionnels  sont  fournis 
sous  forme  de  schemas  electriques.  La  encore,  des 
testbenches  sont  disponibles  ainsi  qu’un  modele 
comportemental  autorisant  les  simulations  de  haut 
niveau  (Verification  «  1  »).  Dans  ce  cas,  I’effort  de 
conception  est,  bien  entendu,  moindre  par  rapport  au 
cas  precedent.  Par  contre  on  ne  maitrise  pas  du  tous 
les  aspects  fonctionnels.  Cela  pent  etre  tres  penible 
durant  le  developpement  si  le  bloc  n’est  pas 
correctement  developpe  et  valide.  De  plus,  les 
modifications  eventuelles  ulterieures  du  SoC  seront 
plus  delicates. 

•  Les  Hard  IP  :  Le  bloc  fonctionnel  est,  dans  ce  cas, 
synthetise,  place  et  route  par  le  fondeur.  Pour 
certains  blocs,  critiques  en  terme  de  performances  en 
vitesse,  ce  choix  est  le  meilleur.  Toutefois,  il  est 
clair  que  Ton  est  entierement  dependant  de  la 
politique  du  fournisseur  ;  On  n’a  aucune  maitrise  sur 
les  aspects  fonctionnels  ni,  pire  encore,  sur  la 
perennite.  Le  fondeur  peut  tres  bien  decider  de  ne 
pas  porter  une  Hard  IP  vers  une  nouvelle 
technologie  tout  en  arretant  celle  utilisee.  La 
situation  alors  delicate  a  gerer,  encore  plus  s’il  s’agit 
d’un  coeur  CPU,  avec  les  impacts  logiciels  associes... 


Les  flots  ASIC  et  LPGA  restent  tres  voisins,  etant 
entendu  qu’il  n’y  a  evidemment  pas  de  fonderie  dans  le 
cas  des  LPGA  mais  la  programmation  d’une  memoire. 

Precisons  que  la  portee  de  ce  §  est  bien  limitee  aux 
circuits  personnalises,  ce  qui  ne  correspond  qu’a  une 
phase  du  developpement  d’un  SoC,  dont  le  fiot  complet 
sera  traite  apres 

Les  IP  ou  « Intellectual  Property  ».  La  notion  de  SoC 
est  indissociable  de  celle  d’lP  (sans  pour  autant  en  avoir 


Les  conditions  d’acces  sont  tres  variees,  rien  de  bien 
stabilise  n’ ay  ant  deja  ete  instaure.  En  general,  il  est 
necessaire  d’acquitter  un  cout  d’acces  a  la  licence,  avec 
en  plus  des  royalties  sur  les  circuits  en  production. 
Notons  que,  dans  certains  cas,  il  n’y  a  pas  de  royalties  et 
qu’il  est  aussi  possible  de  disposer  d’lP  sans  droit 
d’acces  a  la  licence  (meme  pour  certains  IP  consideres 
comme  complexes  tel  que  des  coeurs  CPU)  !  Ceci  dit,  le 
budget  IP  est  generalement  important,  et  dependant  d 
leur  type.  Les  Soft  IP  sont,  bien  sur,  les  plus  chers. 
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Outre  le  classement  precedent,  on  distingue 

generalement  2  grandes  categories  : 

•  Les  «  Commodity  IP  »  :  Ce  sont  les  blocs  d’ usage 
courant.  On  retrouve  les  fonctions  PCI,  USB, 
UART. . .  L’offre  est  tres  riche. 

•  Les  «  Stars  IP  »  :  On  y  classe  traditionnellement  les 
ccEurs  de  processeur  et  les  fonctions  emergentes. 
Toutefois,  force  est  de  constater  que  Ton  assiste,  en 
particulier  pour  les  coeurs  de  processeur,  a  des 
situations  un  peu  abusives.  La  complexite  d’un  tel 
coeur  est,  approximativement,  de  40  000  portes 
(RISC  32  bits  sans  operateurs  flottants),  ce  qui  n’est 
pas  enorme.  Les  couts  (notamment  des  soft  IP),  par 
contre,  sont  generalement  tres  eleves. 

Lors  de  la  selection  des  IP,  il  importe  de  prendre  en 

consideration  : 

•  Les  couts :  Acces  licence,  royalties  mais  aussi 
support  /  maintenance. 

•  La  qualite  des  fournitures.  II  importe  de  savoir  si  un 
minimum  de  regies  de  conception  des  IP  a  bien  ete 
respecte  :  Conception  synchrone,  sur  fronts  montants 


uniquement,  ...  La  facilite  de  I’instanciation  des 
blocs  dans  le  modele  (et  done  couts  et  delais 
associes)  en  depend  largement.  Les  publications  a  ce 
sujet  sont  nombreuses,  on  citera,  par  exemple, 
I’initiative  OpenMore  de  Mentor  /  Synopsys. 

Actuellement,  la  tendance  pour  les  «  Stars  IP  »  est  tres 
orientee  vers  les  Hard  IP  (pour  des  raisons  de  couts  !)  et 
vers  les  Soft  IP  pour  les  autres.  Notons  toutefois  une 
evolution  encore  assez  recente  qui  apparait,  celle  des 
«  Soft  IP  configurables  ».  II  s’agit  de  generer  un  bloc 
suivant  les  besoins  specifiques  (dans  une  certaine 
mesure)  de  I’utilisateur.  Ainsi,  ARC  propose,  moyennant 
le  chargement  via  Internet,  d’un  programme  permettant 
de  creer  un  coeur  de  DSP  et  I’environnement  de 
developpement  logiciel  en  fonction  d’un  certain  nombre 
de  choix.  Tensilica  offre  une  approche  similaire  pent  etre 
plus  aboutie,  aussi  pour  un  coeur  processeur  :  Les  besoins 
utilisateurs  sont  decrits  via  Internet  et  la  Soft  IP  est 
generee  par  Tensilica  et  transferee,  toujours  via  le  net. 
Cette  voie  permet  des  options  de  configuration  plus 
complexes.  Nul  doute  que  cette  voie  a  de  I’avenir,  ainsi 
qu’ Internet  comme  media  de  communication  et 
d’echange. 


Etudes  Systemes 
Essais  Systemes 
Definition  Algorithmes 
Budes  architecture  produit 
Conception  des  Sous-ensembles 
- Materiel 


Prototypes,  adaptations  aisees 


-  Logiciel 

—  Validation 
Transfer!  production 


Prototypes  version  industrielle 


Figure  3  :  Plot  de  developpement  d’un  SoC 


Plot  de  developpement  d’un  SoC 

La  encore,  nombre  de  publications  existent  sur  le  sujet. 
Une  chose  est  sure,  il  n’y  a  pas  de  flot  standard, 
applicable  quel  que  soit  le  type  d’activite  de  la  societe. 
Dans  ce  §,  on  va  done  s’attacher  a  preciser  les  grandes 
etapes  a  prevoir  avec  les  differentes  options  possibles 
pour  chacune  d’elles  ainsi  que  quelques  ecueils  a  eviter. 

On  partira  pour  ce  faire  du  synoptique  de  la  figure  3. 

Le  flot  propose  est  base  sur  la  realisation  d’une  maquette 
a  base  de  FPGA  en  plus  du  developpement  des 


prototypes  en  forme  mettant  en  oeuvre  le  SoC.  C’est  un 
choix  dont  I’interet  est  decrit  dans  un  des  §  suivants. 

Implication  des  equipes  Systeme 

Le  L"  point  a  preciser  est  qu’il  n’est  pas  imaginable  de 
dissocier  les  aspects  Systeme  /  Algorithmique  du 
processus  de  conception  d’un  SoC.  Si  cette  demarche  est 
sans  doute  tres  presente  dans  la  culture  d’entreprises  du 
domaine  des  Telecommunications,  elle  Test  beaucoup 
moins  dans  des  societes,  par  exemple  de  I’aeronautique. 
Deux  raisons  a  cela  : 
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•  L’historique  des  Societes 

•  Les  differences  existant  an  niveau  de  la  notion  de 
systeme.  Dans  le  domaine  de  F  aeronautique,  le 
systeme  met  en  oeuvre  un  ensemble  d’equipements 
complexes,  pas  necessairement  bases  sur  les  memes 
technologies  (mecaniques,  optiques...)- 

Les  responsables  du  Systeme  et  de  la  definition  des 
algorithmes  doivent  etre  tres  impliques  dans  les  etudes 
d’ architecture.  II  est  necessaire  d’optimiser  les 
algorithmes  et  de  les  orienter  en  vue  d’en  faciliter 
r  implementation.  Cette  demarche  etait  classique,  voire 
naturelle  au  tout  debut  de  Felectronique  essentiellement 
a  cause  des  limitations  de  cette  technologie  naissante. 
Elle  s’ est  -  a  tord  -  largement  affaiblie  avec  la 
generalisation  des  structures  programmables.  II  parait 
sain  de  la  remettre  au  gout  du  jour  non  pas  du  fait  de 
limitations  technologiques  mais  plutot  de  couts  en 
production. 

Par  ailleurs,  en  cas  d’erreur  decouverte  une  fois  le  SoC 
realise,  toute  modification  risque  d’etre  longue  et 
couteuse  si  une  solution  logiciel  n’est  pas  applicable. 
Fort  heureusement,  on  commence  a  voir  apparaitre  des 
outils  permettant  la  fourniture  de  Specifications 
Techniques  de  Besoins  (STB)  simulables  done  d’une  part 
validees  par  rapport  aux  besoins  et  d’ autre  part  pouvant 
servir  de  modele  de  reference  pour  la  conception  du  SoC. 
II  convient  enfin  de  noter  qu’il  est  beaucoup  plus  difficile 
de  valider  par  simulation  des  evenements  asynchrones 
que  synchrones.  Meme  si  ce  n’est  pas  toujours  possible, 
on  cherchera  a  les  eviter. 

Le  plan  de  developpement 

Le  2'®”'’  point  important  est  de  definir  en  debut  d’ affaire 
le  plan  de  developpement  et  de  preciser  entre  autres  : 

•  S’il  est  necessaire  de  passer  par  une  phase  maquette. 

•  Les  differentes  etapes  de  validation  et  les  entrees 
necessaires  a  celles  ci. 

•  Le  planning,  bien  entendu,  avec  le  calage  du  debut 
du  developpement  du  prototype  en  forme. 

Passage  par  une  phase  maquette 

II  est  fortement  souhaitable  pour  : 

•  Pouvoir  mettre  au  plus  vite  a  disposition  des  equipes 
Systeme  des  versions  intermediaires  de  calculateur. 

•  Envisager  F  integration  materiel  /  logiciel  avant  de 
pouvoir  disposer  du  prototype  en  forme. 

Besoin  des  equipes  Systeme.  Disposer  au  plus  vite  de 
calculateurs  permet  aux  equipes  Systeme  de  commencer 
progressivement  les  integrations.  II  est  clair  qu’au  debut 
de  celles-ci,  il  n’est  pas  necessaire  de  pouvoir  activer 
toutes  les  fonctionnalites  prevues  pour  le  calculateur.  La 
gestion  des  E/S  sera  done  initialement  proposee  et 
completee  progressivement  en  fonction  des  souhaits  emis 
au  niveau  Systeme. 


Cette  demarche  est  aussi  une  aide  pour  les  concepteurs 
du  calculateur.  Meme  si  les  simulations  permettent 
d’aller  tres  loin  dans  la  validation,  on  ne  pent  simuler  que 
ce  dont  on  a  les  modeles.  Ce  n’est  pas  necessairement  le 
cas  de  tons  les  elements  connectes  au  calculateur.  Dans 
ce  cas,  on  ecrit  un  modele,  mais  qui,  souvent  simplifie, 
ne  represente  pas  toujours  le  comportement  reel.  Les 
essais  avec  les  equipements  reels  sont  de  bon  tests. 

Integration  Logiciel.  L’ autre  interet  majeur  de  disposer 
d’une  maquette  est  de  pouvoir  commencer  F integration 
Logiciel  avant  d’avoir  le  prototype  en  forme.  A  ce  sujet, 
on  voit  apparaitre  une  multitude  d’emulateurs  ou 
d’accelerateurs  Materiel  dont  on  retrouvera  F  interet  au 
niveau  des  simulations  apres  synthese.  Ce  genre  de 
moyen  pent  etre  utilise  pour  faciliter  F  integration  logiciel 
lorsque  Fon  cherche  a  effectuer  celle  ci  en  utilisant  le 
modele  HDL  du  SoC.  Complete  avec  des 
environnements  de  co-simulation  (tel  que  Seamless  de 
Mentor  ou  Eagle-i  de  Synopsys...),  il  est  possible,  pour 
les  equipes  logiciel  et  de  developpement  du  SoC  de 
travailler  chacune  dans  leur  environnement.  De  plus,  en 
simulation,  tons  les  noeuds  internes  du  circuit  sont 
accessibles,  ce  qui  facilite  grandement  le  debuggage. 
Enfin,  au  niveau  du  SoC,  le  logiciel  applicatif  constitue 
un  testbench  reve.  Malheureusement,  il  convient  de 
rester  realiste :  La  puissance  des  machines,  meme 
associees  a  un  accelerateur,  reste  en  de9a  des  besoins 
necessaires  a  la  simulation  d’un  logiciel  applicatif 
complet.  On  limitera  done  cette  approche  au  niveau  des 
handlers  de  base  du  logiciel. 

La  mise  en  oeuvre  d’accelerateurs  n’est  pas  evidente.  Ils 
representent  un  investissement  consequent  et  reposent 
soit  sur  des  structures  proprietaires  soit,  e’est  de  plus  en 
plus  souvent  le  cas,  sur  des  FPGA.  Dans  ce  cas,  bien 
souvent,  il  faut  aussi  disposer  de  la  chaine  de 
developpement  FPGA.  Il  sera  necessaire  de  considerer, 
pour  le  developpement,  la  tache  de  partitionnement  vers 
plusieurs  FPGA  avec  aussi  les  etapes  de 
placement  /  routage  de  chacun  d’eux.  C’est  assez  lourd. . . 
et  redondant  avec  la  maquette.  Enfin  dernier 
inconvenient  relatif  a  ce  genre  d’investissement :  La 
perennite  est  limitee  !  En  effet,  ces  moyens  reposent  sur 
des  technologies  tres  evolutives  (FPGA),  done 
rapidement  obsoletes. 

Les  etapes  de  validation 

Le  synoptique  de  le  figure  3  le  montre,  les  etapes  de 
validation  sont  nombreuses  et  menees  a  bien  par  des 
equipes  differentes.  Par  ailleurs,  on  s’en  doute  bien,  elles 
sont  fondamentales,  d’ou  Finteret  de  les  preparer 
soigneusement.  Il  est  done  largement  souhaitable 
d’etablir  un  plan  de  validation  le  plus  tot  possible  apres 
le  plan  de  developpement  et  decrivant  chaque  etape  de 
validation  avec  les  entrees  /  sorties,  qui  fournit  quoi  et 
qui  fait  quoi.  Cela  presente  les  avantages  : 

•  de  s’ assurer  que  rien  n’aura  ete  oublie  (validation 
de  certains  modes  fonctionnels) 
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•  de  ne  pas  non  plus  valider  2  fois  la  meme  chose,  ce 
qui  pent  couter  cher  en  temps 

•  de  fiabiliser  le  planning  de  developpement,  en 
precisant  les  responsabilites. 

Ce  plan  de  validation  doit  etre  tenu  a  jour  et  enrichit  en 
permanence. 

On  se  limitera,  dans  ce  §,  aux  validations  fonctionnelles. 
Les  techniques  de  validation  sont  essentiellement  basees 
sur  des  simulations,  associees  a  des  essais  effectues  avec 
les  maquettes  et  prototypes. 

Les  simulations.  Plus  les  simulations  sont  faites  a  haut 
niveau,  plus  elles  sont  rapides.  On  a  done  tout  interet  a 
envisager  de  commencer  au  niveau  Systeme,  en  creant 
des  Specifications  Techniques  de  Besoins  simulables. 
Les  validations  de  haut  niveau  peuvent  ainsi  etre  faites 
directement  par  I’equipe  systeme  ce  qui  est  plus  efficace. 

Au  niveau  des  modeles  developpes  pour  les  besoins  de  la 
phase  Maquettage,  la  priorite  est  d’en  disposer 
rapidement.  Les  simulations  sont  done  reduites  (ce  qui  ne 
veut  pas  dire  supprimees),  mais  completees  par  des 
essais  sur  table. 

Le  SoC,  quant  a  lui,  doit  etre  valide  de  maniere  intensive 
et  a  toutes  les  etapes  de  conception.  II  convient  de  noter 
que  les  simulations  fonctionnelles  sont  longues. 

Au  niveau  du  modele  HDL,  le  temps  passe  est 
essentiellement  du  a  la  definition  des  themes  de  test  et  a 
la  creation  des  testbenches  correspondants.  De  plus,  il  est 
souvent  difficile  de  savoir  si  la  validation  est  exhaustive 
ou  non.  C’est  particulierement  vrai  pour  des  applications 
de  traitement  d’images.  Par  contre,  les  temps  machine 
restent  acceptables. 

Par  ailleurs,  il  faudra  bien  comparer  les  resultats  de 
simulation  par  rapport  a  une  reference  et  ce  de  maniere 
automatique.  On  voit  bien,  la  encore,  I’interet  de  disposer 
d’une  Specification  Technique  de  Besoins  simulable. 
Pour  revenir  a  la  definition  des  themes  de  test,  il  est 
important  d’y  associer,  bien  sur  les  concepteurs  du  SoC, 
mais  aussi  les  utilisateurs  : 

•  au  niveau  systeme,  y  compris  les  responsables  de  la 
definition  des  algorithmes,  et  ce  pour  eviter  toute 
incomprehension 

•  au  niveau  carte,  de  maniere  a  fiabiliser  la  definition 
des  interfaces  avec  le  reste  des  circuits  des  cartes. 

•  au  niveau  logiciel,  c’est  aussi  a  ce  niveau  que 
Tutilisation  des  handlers  logiciel  de  base  constitue 
un  excellent  testbench,  ainsi  que  cela  a  deja  ete 
precise. 

Apres  synthese  et  placement  /  routage,  les  temps  des 
simulations  fonctionnelles  sont  fondamentalement 
prohibitifs.  Pour  assurer  la  coherence  des  tests,  elles  ont 
pour  base  les  testbenches  definis  au  niveau  de  la 
validation  du  modele  HDL.  Mais,  du  fait  de  la  forte 
complexite  de  ces  circuits,  les  temps  machine  sont 
importants,  pouvant  durer  plusieurs  semaines  (sur 


plusieurs  stations  de  travail).  On  limite  done  ce  type  de 
simulation  au  strict  minimum  et  on  s’ attache  plutot  a 
utiliser  un  outil  d’ analyse  statique  de  timing.  Celui  ci  est, 
de  toute  fa9on  indispensable  a  une  validation  correcte  au 
niveau  structurel  (apres  synthese).  Eventuellement,  des 
outils  de  preuve  formelle  peuvent  constituer  aussi  une 
aide  mais  ils  ne  marchent  generalement  pas  tres  bien 
pour  des  structures  algorithmiques  complexes,  du  moins 
actuellement. 

Essais  sur  table.  Ce  type  d’essai  est  tres  classique.  On 
notera  tout  de  meme  : 

•  I’interet  qu’il  y  a  de  bien  les  formaliser  de  maniere 
a  eventuellement  les  transformer  en  testbench 

•  en  cas  de  probleme,  I’importance  qu’il  y  a  de 
fiabiliser  la  coherence  des  prises  en  compte  des 
corrections  au  niveau  des  maquettes  (FPGA)  mais 
aussi  au  niveau  du  SoC 

Enfin,  meme  sur  maquette,  en  cas  de  probleme,  il  est 
souvent  plus  facile  d’en  trouver  I’origine  en  simulation 
oil  Ton  a  acces  a  F ensemble  de  noeud  du  circuit,  plutot 
que  sur  la  realisation  materielle. 

La  gestion  des  plannings 

On  F  a  vu,  une  bonne  gestion  des  etapes  critiques  permet 
logiquement  de  fiabiliser  le  planning  de  developpement. 
L’ autre  aspect  a  maitriser  est  la  relation  avec  les 
intervenants  exterieurs. 

Sous-traitance  de  conception  :  Elle  n’est,  bien  sur,  pas 
obligatoire.  Dans  le  cas  ou  on  y  a  recourt,  en  particulier 
pour  la  conception  de  blocs  fonctionnels  en  HDL,  il  est 
souhaitable  d’imposer  des  regies  de  conception  qui 
permettent  de  s’ assurer  de  la  qualite  de  conception  et 
d’un  interfa9age  aise  avec  le  reste  du  circuit 

La  encore,  les  recommandations  definies  dans  le  cadre  de 
F  initiative  OpenMore  sont  une  excellente  base. 

Il  est  aussi  largement  preferable  que  le  sous-traitant 
utilise  les  memes  outils  de  conception  que  ceux  mis  en 
oeuvre  dans  la  societe. 

Placement  /  routage,  relations  avec  le  fondeur :  Il 

s’agit  d’un  cas  un  peu  particulier  de  sous-traitance.  C’est 
souvent  le  fondeur  qui  se  charge  du  placement  /  routage 
etape  souvent  assez  delicate  et  qui,  en  cas  de  probleme 
pent  durer  fort  longtemps.  Deux  regies  essentielles  sont  a 
respecter  : 

•  Meme  si  Fon  cherche  a  etre  independant  des 
technologies,  il  est  souhaitable  de  selectionner  le 
fondeur  au  plus  tot,  et  de  mettre  en  place  des 
echanges  sur  Favancement  du  projet  et  les  regies  de 
conception  qu’il  peut  vouloir  imposer. 

•  Avant  d’envoyer  un  circuit  pour  le 
placement  /  routage,  on  aura  tout  interet  a  passer 
par  une  etape  de  pre-placement,  et  de  prendre  en 
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compte  le  routage  de(s)  horloge(s).  Cela  evite 
nombre  d’allers  /  retours,  souvent  penibles  et  longs. 

Plannings  trop  optimises  ;  Bien  sur,  le  developpement 
doit  etre  le  plus  court  possible.  II  ne  faut  tout  de  meme 
pas  tomber  dans  le  piege  consistant  a  «  oublier  »  des 
taches.  En  particulier,  il  ne  faut  pas  considerer  que,  parce 
qu’on  utilise  des  IP,  il  n’y  a  aucun  effort  de  conception  a 
prevoir.  Il  y  a  generalement  une  logique  d’interfa9age  a 
concevoir.  Un  bon  exemple  est  celui  du  couplage  d’un 
coeur  CPU  sur  un  bus  on-chip.  Il  serait  bien  surprenant 
que  les  2  blocs  aient  ete  con9US  en  meme  temps,  sans 
evolution  aucune  de  Pun  par  rapport  a  1’ autre. 

Recouvrement  des  activites  de  conception  FPGA 
(maquette)  /  SoC  ;  A  condition  de  bien  le  prevoir  au 
niveau  de  1’ architecture  des  circuits,  il  est  imaginable  de 
reprendre  des  blocs  HDL  developpe  pour  la  maquette 
pour  le  SoC  proprement  dit  et  inversement.  Par  contre,  il 
faudra  faire  attention  a  la  coherence  des  fichiers,  en 
particulier,  suite  a  la  prise  en  compte  des  evolutions. 

Integration  Materiel  /  Logiciel  et  Systeme 

Ce  theme  a  deja  ete  aborde  pour  justifier  I’interet  de  la 
phase  Maquette.  Toutefois,  a  un  moment  donne,  il  faudra 
bien  integrer  le  prototype  en  forme  avec  le  SoC. . .  et  bien 
sur,  il  y  aura  des  problemes  ! 

Au  niveau  logiciel,  les  techniques  de  debuggage  n’ont 
aucune  raison  d’etre  differentes  de  celles  utilises  avec 
des  structures  programmables  classiques. 

Au  niveau  systeme,  il  est  certain  qu’il  faut  prevoir  des 
dispositifs  integres  dans  le  SoC  et  permettant  -  au 
minimum  -  de  connaitre  les  donnees  echangees  entre 
blocs. 

Enfin,  rappelons  I’interet  qu’il  y  a  a  disposer  d’un 
modele  et  permettant  un  debuggage  souvent  facilite, 
moyennant  la  definition  d’un  test  precis. 

Technologie  et  perennite 

Avantages  /  inconvenients  de  I’approches  SoC 

Les  avantages  de  F  approche  decrite  se  retrouve  a  divers 
niveaux  : 

Les  aspects  thermiques,  la  consommation  :  L’ integration 
silicium  permet  souvent  de  diminuer  la  puissance 
dissipee.  Si  la  consommation  n’est  generalement  pas  un 
probleme  pour  des  applications  aeronautiques,  les 
aspects  thermiques  eux  le  sont.  Le  choix  d’une 
technologie  ASIC  (avec  fonderie)  par  rapport  a  une 
filiere  EPGA  est,  a  ce  sujet  preferable. 

Les  couts  en  production  :  Les  structures  de  ce  type  sont 
beaucoup  plus  simples,  mettant  en  oeuvre  moins  de  cartes 
et  moins  de  composants.  Autant  de  facteurs  reducteurs  de 


cout  en  production.  La  consommation  diminuant,  on 
gagne  aussi  sur  la  complexite  des  blocs  alimentation. 

Les  dispositifs  de  drainage  des  calories  se  simplifient. 

La  fiabilite  :  La  maitrise  de  la  consommation  et  la 
reduction  du  nombre  de  composants  permettent 
d’ameliorer  la  fiabilite  des  calculateurs. 

Les  inconvenients  :  Bien  sur,  il  y  en  a  toujours  : 

Acces  fonderie  ;  Dans  le  cas  du  developpement  d’un  SoC 
base  sur  une  technologie  ASIC  (par  opposition  a  LPGA). 
La  lithographie  a  utiliser  sera  du  0.25  ou  0.18  pm.  Les 
couts  de  realisation  des  masques  sont  importants.  De 
plus,  les  fondeurs,  surtout  actuellement,  recherchent  de 
gros  volumes  ce  qui  n’est  absolument  pas  notre  cas  au 
niveau  des  applications  aeronautiques.  Il  convient  de 
remarquer,  pour  ces  2  aspects  que  ce  debat  sur  Faeces 
aux  fonderies  date  du  debut  de  la  technologie  ASIC. 
Jusqu’a  maintenant,  nous  avons  toujours  trouve  des 
fondeurs  acceptant  de  travailler  avec  nous.  Par  ailleurs, 
des  techniques  d’ acces  multi -projects  wafer  et  multi  level 
mask  se  developpent,  limitant  Fen  vole  du  prix  des 
masques. 

Conditions  d’achat :  C’est  bien  connu  ;  Les  societes  ont 
horreur  d’acheter  de  grosses  quantiles  couvrant  les 
besoins  de  plusieurs  annees.  C’est  malgre  tout  ce  qu’il 
faut  se  preparer  a  faire  !  En  effet,  pour  un  SoC  developpe 
en  technologie  ASIC,  on  demandera  au  fondeur  de  lancer 
un  batch  de  wafers,  ce  qui  representera  sans  doute  si  ce 
n’est  toute,  au  moins  une  bonne  partie  de  la  serie  !  Ceci 
dit,  ce  probleme  est  aussi  de  plus  en  plus  souvent 
rencontre  dans  le  cadre  de  Futilisation  de  composants 
civils,  et  done  de  FPGA. 

Risques  et  couts  de  developpement :  Des  que  Fon  parle 
ASIC,  on  voit  souvent  les  cheveux  de  dresser  sur  la  tete 
de  nos  interlocuteurs  !  A  lord  !  Finalement,  le  cout  de 
developpement  d’une  fonction  en  ASIC  est  similaire  a 
celui  d’une  structure  programmable  aux  couts  de 
fonderie  prets.  Meme  si  ces  demiers  sont  eleves,  ils  ne 
sont  malgre  tout  pas  redhibitoires  par  rapport  aux  couts 
de  developpement  d’un  calculateur.  Par  ailleurs,  les 
outils  et  les  methodologies  utilises  permettent  de 
largement  fiabiliser  le  developpement  et  de  done  de 
reduire  les  risques. 

Souplesse  :  Bien  sur,  une  fois  la  phase  de  fonderie 
terminee,  il  est  sinon  difficile  en  tout  cas  long  et  couteux 
de  modifier  une  fonction  pour  prendre  en  compte  une 
evolution.  Il  est  important  d’ insister  la  sur  Fetape 
d’ architecture  de  maniere  a  rendre  la  structure 
parametrable  (exemple  :  pouvoir  modifier  les  parametres 
d’un  filtre  par  programmation).  De  plus,  on  Fa  vu,  le 
SoC  integre  beaucoup  de  blocs  standards,  le  tout  controle 
par  logiciel  du  fait  de  Fintegration  d’un  coeur  CPU  (ou 
plusieurs).  L’idee  de  circuits  ASIC  rigides  n’est  done 
plus  vraiment  de  mise  et,  en  tout  cas  ne  Fa  jamais  ete 
pour  les  technologies  FPGA.  Enfin,  le  cote  positif  est  que 
«  Reflechir  avant  d’agir»  permet  souvent  d’eviter  des 
erreurs  et  de  gagner  en  temps  de  developpement... 
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SoC  :  Le  choix  FPGA  /  ASIC 

Meme  si  la  decision  est  prise  de  s’orienter  vers  du 
FPGA,  il  est  souhaitable  de  conserver  la  possibilite  de 
migrer  vers  de  I’ASIC  et  done  d’appliquer  les  regies 
idoines.  On  commence  a  voir  apparaitre  des  FPGA 
integrant  des  coeurs  de  processeur :  Attention  a  la 
compatibilite  avec  une  possible  filiere  ASIC. 

Le  FPGA  est,  bien  entendu,  plus  souple  en 
developpement  en  cas  d’ evolution  mais  est  notablement 
plus  cher  en  production.  II  faut  done  faire  un  bilan 
economique  en  fonction  des  quantites  a  produire. 

Le  FPGA  presente  aussi  le  risque  d’ obsolescence.  Alors 
que  les  memoires  SRAM  etaient  le  vehicule 
technologique  utilise  par  les  fondeurs  pour  mettre  au 
point  les  nouvelles  lithographies,  elles  out  ete  remplacees 
par  les  FPGA  qui  out  aussi  une  structure  reguliere  et 
pour  lesquels  on  assiste  a  Fen  vole  des  complexites.  Ces 
composants  sont  done  a  la  pointe  des  technologies,  mais 
cette  course  risque  de  laisser  rapidement  de  cote  les 
versions  a  peine  plus  anciennes.  II  y  aura,  bien  sur,  des 
FPGA  permettant  de  remplir  la  fonction,  mais  la 
compatibilite  avec  la  carte  n’est  pas  assuree. 

Au  moment  du  choix,  il  convient  d’etre  prudent  par 
rapport  a  la  realite  des  complexites  annoncees  par  les 
fournisseurs  de  FPGA.  1  million  de  portes  FPGA  est  loin 
d’etre  equivalent  a  1  million  de  partes  ASIC  !  En  plus  le 
rapport  est  variable  en  fonction  des  fournisseurs  et  meme 
des  families.  Idem  pour  les  vitesses  qui  correspondent 
souvent  a  des  «  best  case  »,  e’est  a  dire  la  frequence 
maximum  avec  des  fan  out  de  1 . . .  ce  qui  est  rarement  le 
cas  dans  la  realite  ! 

La  perennite 

Ce  theme  est  la  trame  de  ce  document  en  entier,  avec, 
toutefois,  quelques  aspects  complementaires. 

Propriete  du  circuit ;  La  societe  est  proprietaire  de  son 
design  et  du  modele  HDL.  Moyennant  le  respect  de 
quelques  regies,  le  portage  d’une  technologie  vers  une 
autre  n’est  pas  un  probleme  majeur. 

Une  limitation  existe  en  cas  d’ utilisation  de  Firm  ou 
Hard  IP,  pour  lesquelles  il  faudra  se  limiter  a  de  grands 
standards  du  marche. 

A  noter,  que,  a  ce  niveau,  il  ne  s’agit  pas  de  dire  que  la 
technologie  (lithographie)  ne  deviendra  pas  obsolete.  Par 
contre  le  fait  de  pouvoir  migrer  vers  une  autre,  meme  si 
les  couts  ne  sont  pas  nuls,  permet  d’eviter  la  reprise  de 
cartes  et  pire  encore  du  logiciel. 

Conditions  d’achat :  Celles  la  meme  evoquees 
precedemment  et  presentees  comme  un  inconvenient  !  Le 
fait  de  faire  du  stock  en  quantite  suffisante  pour  la  serie 
met  a  I’abrie  de  tout  surcout  du  fait  de  problemes 
d’ obsolescence... 


Gamme  de  temperature  de  fonctionnement :  A  partir 
du  moment  oil  la  societe  controle  F  ensemble  du 
developpement,  il  est  parfaitement  possible  de  valider  le 
SoC  (les  timings)  sur  une  gamme  de  temperature 
correspondant  a  nos  besoins.  En  production,  si  le  fondeur 
refuse  d’effectuer  les  tests  en  temperature,  il  est  encore 
possible  de  realiser  ou  de  faire  realiser  des  tests 
specifiques  puisque  Fon  est  aussi  proprietaire  des 
vecteurs  de  test. 


Conclusion 

L’approche  SoC  necessite  d’ adapter  certaines  methodes 
de  developpement  au  niveau  validation  par  exemple  et 
d’effectuer  un  controle  rigoureux  du  developpement.  Par 
contre,  elle  est  particulierement  attractive  sur  les  plans 
des  performances  au  sens  large  mais  aussi  de  la 
perennite. 
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1.  SUMMARY 

This  paper  describes  how  to  design  open  computer 
systems  for  mission  critical  applications  within  the 
avionics  of  military  aircraft  using  “Commercial  Off  The 
Shelf‘  (COTS)  computer  components*.  Design  aspects  of 
“Integrated  Modula  Avionics”  (IMA)  are  incorporated. 
How  these  aspects  contribute  to  an  effective  obsolescence 
management  is  also  described.  The  content  of  this  paper  is 
presented  within  the  context  of  projects  currently  running 
at  the  European  Aeronautic  Defence  and  Space  (EADS) 
Deutschland  GmbH,  Military  Aircraft  Business  Unit 
(MABU),  which  are  dealing  with  the  subjects  COTS  and 
obsolescence. 

Eirst  the  primary  design  aspects  of  open  computer  systems 
will  be  discussed  as  well  as  internationally  recognised 
associations  and  standards  dealing  with  this  topic.  The 
potential  behind  the  use  of  open  computer  systems  for 
future  avionics  of  military  aircraft  is  to  be  unveiled. 

It  will  be  described,  how  to  set  up  open  computer  systems, 
considering  IMA  conform  design  aspects,  which  fulfil  the 
requirements  directed  to  the  equipment  of  mission  critical 
avionics  in  military  aircraft.  Within  this  context  the  core 
aspects  of  IMA  will  be  introduced  and  compared  to 
conventional  systems. 

Regarding  design  aspects  for  open  computer  systems  the 
design  principals  developed  by  the  Allied  Standard 
Avionics  Architecture  Council  (ASAAC)  have  to  be 
mentioned.  Eirms  of  the  three  participating  countries  - 
England,  France  and  Germany  -  are  co-operating  to  set  up 
a  European  accepted  standard  for  avionics  HW  and  SW 
designed  for  use  in  military  aircraft. 

The  use  of  COTS  computer  HW  and  SW  will  be 
presented  as  a  cost  effective  solution  for  setting  up  open 
computer-systems  for  use  in  aircraft,  until  ASAAC 
conform  HW  and  SW  solutions  are  available.  Possible 
COTS  based  configurations  will  be  discussed  referring  to 
a  current  COTS  computer  system.  This  system  is 
ruggedised  for  flight  and  built  up  with  COTS  HW  and  run 
by  a  COTS  real  time  operating  system.  Successful  flight¬ 
testing  of  the  system  has  taken  place. 

Due  to  the  rapid  developing  IT  technology,  today’s 
computer  systems  quickly  face  obsolescence.  Avionics  for 
military  aircraft  are  especially  vulnerable  because  of  the 


’  Thereby  processor-boards,  I/O-boards,  chassis,  operating  systems  etc. 
are  referred  to,  which  are  available  fully  developed  at  the  commercial 
market. 


long  development  cycles.  The  opportunities  of  managing 
obsolescence,  given  by  the  use  of  COTS  computer  HW 
and  SW,  are  identified  with  respect  to  future  avionics  of 
military  aircraft.  Affected  qualification  and  flight- 
clearance  aspects  as  well  as  the  porting  of  avionics  SW- 
applications,  originally  developed  for  proprietary 
computer  systems,  onto  COTS  computer  systems  will  be 
mentioned. 

2.  OPEN  SYSTEM  ARCHITECTURES 

The  majority  of  computing  systems  in  service  in  military 
aircraft  of  today,  show  a  proprietary  system  architecture^. 
They  are  designed  as  Line  Replaceable  Units  (LRUs) 
developed  for  special  functions  or  cover  a  cluster  of 
functions.  Fitted  together  in  the  avionics  of  the  EF2000, 
LRUs  can  be  found  for  example  as  DASS  computer,  as 
navigation  computer,  as  digital  symbol  generator  etc. 
(Figure  1).  Mostly  HW  and  OS  of  these  LRUs  are 
invariant.  Therefore  modifications,  as  well  as 
enhancements  and  technical  innovations,  that  become 
necessary  during  the  life  cycle  of  a  LRU,  maybe  can’t  be 
carried  out.  Any  cross  use  of  proprietary  computer 
systems  for  different,  mission-critical  avionics  functions 
may  not  be  practicable  due  to  their  specific  system  design. 
Each  function  is  implemented  on  a  specially  developed 
computer  system,  integrated  as  LRU  in  the  aircraft 
avionics. 

Today  avionics  systems  of  military  aircraft,  based  on 
LRUs  designed  for  special  functions,  represent  a 
symbiosis  of  multiple  LRUs.  Thereby  the  high  complexity 
of  avionics  systems,  due  to  their  comprehensive 
functionality,  is  further  driven  by  the  specific  properties 
of  the  different  LRUs  -  proprietary  external  HW 
interfaces,  data-protocols  etc..  Development,  production, 
integration  testing,  logistics,  maintenance  and  upgrading 
of  today’s  avionics  systems  are  therefore  comprehensive 
and  cost  intensive  over  the  whole  lifecycle. 

2.1  Main  Design- Aspects 

Pushed  by  the  described  deficits  of  current  LRUs,  open 
system  architectures  are  required  for  future  avionics  of 
military  aircraft.  The  core  aspect  of  open  systems  is  a 
flexible  system  design  based  on  well  established  HW  and 


^  Today’s  avionics  computer  already  follow  a  modulare  HW  and  SW 
design.  However  modules  and  components  are  coupled  via  supplier 
specific  HW  and  SW  interfaces. 
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SW  interfaces.  By  using  open  systems  it  is  expected  [1]  to 
overcome  the  deficits  of  current  LRUs: 

•  Avionics  equipment  following  flexible  HW  and  SW 
concepts  shall  support  the  use  of  state  of  the  art 
technology. 

•  An  open  architecture  can  shorten  equipment 
development  and  secure  the  upgrade  potential  needed. 

•  The  scope  of  possible  HW  and  SW  solutions  will 
grow. 

•  A  well  established  upgrade  potential  and  enhanced 
resource  procurement  shall  help  to  reduce  the 
pressing  obsolescence  risks  encountered  with  current 
avionics  equipment. 

•  Development,  procurement  and  lifecycle  costs  can  be 
significantly  reduced. 

•  The  integration  of  components  into  an  equipment  as 
well  as  the  integration  of  equipment  into  an  existing 
network,  like  the  avionics  of  a  military  aircraft,  shall 
be  eased. 

•  The  previously  described  scope  of  open  system 
architectures  is  established  via  HW  and  SW  offered  in 
the  commercial  market. 

Applied  to  computer  systems  for  the  avionics  of  military 
aircraft  this  implies  the  following  focal  aspects  for  an 
open  system  design  [2]  to  be  considered  during  the 
definition  phase  of  a  computer  system: 

•  A  modular  system  design  with  mechanical  and 
electronic  autonomous  components^,  similar  to  that  of 
modern  LRUs,  has  to  be  followed. 

•  The  integration  of  such  components  into  a 
functioning  system  has  to  follow  clearly  defined,  fully 
developed,  commercially  supported  and  therefore 
stable  HW  and  SW  interfaces.  This  refers  to  both 
external  and  internal  HW  and  SW  interfaces. 

•  HW  and  SW  interfaces  chosen  for  open  system 
architectures  have  to  be  available  to  a  broad  clientele 
of  users  and  should  be  continuously  maintained  and 
further  developed  by  internationally  recognised 
standardisation  institutions. 

•  HW  and  SW  interfaces  suited  for  open  computer 
systems  have  to  support  modifications  and  upgrades 
of  existing  and  future  avionics  applications. 

•  The  HW  configuration  of  open  computer  systems 
must  feature  quick  and  easy  maintenance  and  upgrade 
possibilities,  e.g.  well  established  interfaces,  which 
guarantee  the  exchangeability  of  inoperative  or 
obsolete  components,  boards  and  parts  against  state- 
of-the-art  solutions.  Within  chassis  spare  slots  must 
be  available  for  the  insertion  of  additional  boards. 

2.2  International  Efforts 

Efforts  to  establish  open  systems  in  military  equipment 
find  their  origin  in  the  USA.  They  were  initiated  by 
William  Perry,  1994  Secretary  of  Defense  and  a  strong 
advocate  of  an  intensive  usage  of  commercially 


^  Such  components  are  designed  as  Embedded  Systems,  e.g.  as  SBC, 
combining  dedicated  equipment  functions. 


established  standards,  specifications  and  state-of-the-art 
technology. 

The  same  year  Dr.  Kaminski,  Under  Secretary  of  Defense 
for  Acquisition  &  Technology,  strengthened  this  direction 
when  announcing,  that  new  acquisitions  of  electronic 
equipment  have  to  follow  an  open  system  architecture.  To 
support  this  process  he  founded  the  Open  Systems  Joint 
Task  Force  (OS-JTF)  and  established  it  as  an  institution. 

Due  to  this  announcement  of  the  Department  of  Defense 
(DoD)  concerning  military  command,  control, 
communications,  computer  and  intelligence  (C4I) 
systems,  documents  were  set  up,  which  describe 
definition,  specification  and  development  guidelines  for 
open  systems  as  well  as  the  related  HW  and  SW 
interfaces.  Leading  documents  related  to  this  topic  are  [3]: 

•  Joint  Technical  Architecture  (JTA)  framework 

•  Joint  Aeronautical  Commanders  Group  (JACG)  guide 
specifications 

•  Generic  Open  Architecture  (GOA)  framework 

•  Technical  Reference  Codes  (TRCs) 

•  Technical  Architecture  Framework  for  Information 
Management  (TAFIM),  cancelled  in  January  2000 
and  replaced  by  the  current,  equivalent  JTA 
standards. 

By  the  Institute  of  Electrical  and  Electronic  Engineers 
(IEEE)  open  systems  are  defined  via  two  basic  standards: 

•  P1003.0/D15  Open  Specification"* 

•  P 1 003 .0/D  1 6  Open  System  Environment 

These  standards  are  accompanied  by  further  IEEE 
standards. 

2.3  Potential  for  Realisation 

Open  systems  are  principally  suited  for  all  kinds  of 
avionics  systems  in  military  aircraft.  Due  to  the  strong 
adherence  of  open  architectures  to  well  established 
interfaces,  avionics  computer  systems  are  especially 
suited  for  first  introduction.  HW  and  SW  computer 
components  have  experienced  a  broad  entry  in  many 
different  industries.  An  intensive  competition  between  the 
different  suppliers  of  computer  components  has  led  to 
standardised  HW  and  SW  interfaces,  which  were  quickly 
and  widely  accepted,  e.g.: 

•  VME,  PCI  or  cPCI  are  well  established  data-bus 

interfaces  for  coupling  different  computer 

components 

•  ATR  is  a  standard  for  chassis,  ruggedised  for  flight 

•  As  standard  format  for  the  geometry  of  computer 
boards  Eurocard  is  used 

•  POSIX  is  established  as  SW  standard  for  application 
and  user  interfaces 

Regarding  this  selection  of  standards  already  helps  to  fit 
together  HW  and  SW  components  according  to  the 
principals  of  open  system  architectures,  summarised  by 


"*  “Public  specifications  that  are  maintained  by  an  open,  public 
consensus  process  to  accommodate  new  technologies  over  time  and 
that  are  consistent  with  international  standards”,  Open  Specification 
Definition  IEEE  P1003.0/D15.. 
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the  OS-JTF  [1]  in  the  Electronics  Reference  Model 
(Figure  2).  A  central  design  aspect  of  this  model  is  a 
layered  HW  and  SW  architecture.  The  single  layers  of  this 
model  can  communicate  with  each  other  via  the  SW  and 
HW  interfaces  listed  above.  A  computer  system,  based  on 
the  layered  architecture  of  the  Electronics  Reference 
Model,  is  open  for  the  exchange  of  single  HW  and  SW 
computer  components.  This  helps  to  reduce  obsolescence 
risks  associated  with  computer  systems. 

Computer  HW  and  OSs,  which  satisfy  the  standards  listed 
above  and  classified  as  ruggedised  for  flight,  can  be 
bought  on  the  commercial  market.  Euture  aircraft 
programs  as  well  as  facing  upgrades  of  aircraft  in  service 
may  use  existing  COTS  computer  HW  and  SW  to  design 
open  computer  systems  for  use  in  military  aircraft. 
Existing  and  newly  developed  avionics  SW  applications 
have  then  to  be  aligned  to  a  layered  architecture, 
described  by  the  referred  Electronics  Reference  Model. 

A  first  approach  will  have  to  be  restricted  to  mission 
critical  computer  systems  to  reduce  the  risk  always 
associated  with  the  introduction  of  new  technologies. 

3.  KORRELATION  WITH  INTEGRATED 
MODULAR  AVIONICS  (IMA) 

Design  principals  of  open  systems  conform  with  the  basic 
principals  of  Integrated  Modular  Avionics,  although  IMA 
goes  much  further. 

Regarding  the  actual  needs  of  aircraft  operators  IMA  [4] 
propagates  modular  architectures  for  avionics  systems. 
Intentions  of  IMA  are: 

•  Improved  maintenance  of  Avionics  systems. 
Adaptations  and  enhancements  during  the  lifecycle  of 
avionics  systems  have  to  be  simplified  . 

•  To  introduce  a  refined  fault  tolerance  and  fault 
management  for  avionics  systems  concerning 
detection,  isolation  and  correction  of  in  flight  faults. 

•  To  take  advantage  of  shorter  technology  development 
cycles  for  avionics. 

Applied  to  the  HW  of  avionics  computers  IMA  conform 
configurations  will  consist  of  components  coupled  via  few 
dedicated  HW  and  SW  interfaces.  These  interfaces 
comply  with  international  established  standards.  Within 
such  computer  systems,  components  can  easily  be 
exchanged  and  replaced  by  further  or  completely  new 
developed  components.  Due  to  that,  obsolescence  risks 
are  reduced.  A  further  central  design  aspect  derived  from 
IMA  is  to  build  up  component  clusters  within  cabinets^, 
which  serve  as  data  management  centres.  Step  by  step  this 
development  direction  of  avionics  computers  has  then  to 
be  applied  to  further  avionics  systems.  Therefore,  in  the 
future  the  design  of  military  avionics  will  no  longer  be 
determined  by  multiple,  separate  computer  systems  or 
LRUs,  coupled  via  data-busses  and  point-to-point 
connections.  Consequently  the  diversity  of  electronic 
components  in  today’s  chassis  respectively  LRUs  will  be 


^  Contrary  to  chassis  in  service  today,  cabinets  are  part  of  the  aircraft 
structure  and  represent  mounting  areas  for  a  number  of  processor 
boards,  I/O  boards  etc.. 


reduced.  Instead  common  modules,  components  which  are 
available  in  a  few  variants  only,  will  handle  different 
avionics  functions.  These  common  modules  will  be 
mounted  in  a  small  number  of  cabinets,  connected  via 
high  speed  data-busses,  operating  with  a  high  bandwidth. 
In  case  of  an  in  flight  HW  or  SW  failure,  an  in  flight 
reconfiguration  of  the  avionics  system  enables  avionics 
functions  to  be  maintained,  depending  on  the  severity  of 
the  failure  that  has  occurred  and  the  necessity  of  a 
function  for  save  aircraft  operation.  Thereby  a  greater 
redundancy  of  avionics  functions  is  reached  with  less 
components  compared  to  the  number  of  components 
needed  for  redundancy  purposes  in  today’s  avionics 
systems. 

Associated  with  avionics  SW,  IMA  follows  a  strict 
subdivision.  It  distinguishes  between  SW  applications  for 
pure  avionics  functions,  the  OS  and  the  driver  SW  for 
operating  the  HW  components  of  an  equipment.  These 
three  autonomous  SW  components  are  related  via  highly 
standardised  SW  interfaces  and  together  make  up  the  SW 
of  an  avionics  equipment. 

Avionics  equipment  following  IMA  design  aspects  shows 
a  modular  system  architecture,  based  on  few  variants  of 
common  HW  and  SW  components,  which  can  be  used  for 
different  avionics  applications.  The  subdivision  of  the  SW 
of  an  avionics  equipment  as  well  as  the  communication 
between  the  equipment’s  HW  components  via  well 
established,  highly  standardised  interfaces,  e.g.  VME, 
cPCI  etc.,  lead  to  an  equipment  architecture,  classified  by 
SW  and  HW  layers.  These  layers  are  again  coupled  via 
well  established,  highly  standardised  interfaces  and  make 
up  the  technical  layout  of  modern  IMA  avionics 
equipment.  Such  a  layered  architecture  corresponds  with 
the  Electronics  Reference  Model  mentioned  in  Chapter 
2.3  as  an  architecture  for  open  systems.  Therefore  this 
model  can  be  referred  to  as  a  development  step  for  current 
avionics  towards  IMA. 

Looking  beyond  the  establishment  of  open  systems, 
ASAAC  is  producing  a  set  of  IMA  implementation 
standards.  ASAAC  is  run  by  aerospace  and  IT  companies 
in  a  tri  national  alliance  between  the  participating 
countries  England,  Erance  an  Germany. 

4.  IMPLEMENTION  GUIDELINES  FOR  OPEN 
SYSTEM  ARCHITECTURES 

Currently  two  different  implementation  concepts 
correlating  with  each  other,  ASAAC  and  COTS,  are 
followed  by  EADS  Deutschland  GmbH  to  introduce  open 
systems  in  military  aircraft  avionics.  Both  concepts  follow 
different  priorities  and  time  scales.  ASAAC  is  directed  to 
the  long-term  and  focused  on  a  completely  IMA  reliant 
avionics  in  military  aircraft.  Until  ASAAC  conform  HW 
and  SW  components  are  available,  future  configurations 
of  avionics  computer  can  make  use  of  COTS.  The  focus 
of  this  concept  is  short-term,  propagating  a  cost  saving 
introduction  of  open  systems  in  avionics,  thereby 
contributing  to  the  mitigation  of  the  obsolescence  risks 
related  with  current  avionics  systems. 
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4.1  ASAAC 

ASAAC  is  working  towards  the  establishment  and 
demonstration  of  standards  for  defining  the  architecture  of 
modular  avionics  for  military  aircraft  within  the  next  four 
years.  First  ASAAC  related  HW  and  SW  components 
shall  be  available  on  the  commercial  market  in  2005.  In  a 
next  step  the  ASAAC  standards,  agreed  by  the  three 
European  partner  nations,  shall  become  NATO  standard 
(STANAG).  Focal  point  of  all  ASAAC  efforts  towards 
modular  avionics  for  military  aircraft  is  a  layered  HW  and 
SW  architecture  (Figure  3).  Within  ASAAC,  the 
Electronics  Reference  Model,  referred  to  in  chapter  2.3  as 
layered  architecture  model  for  open  system  designs,  is 
experiencing  a  refinement.  The  Application  Layer  (AL)  is 
the  upper  layer  of  the  ASAAC  architecture  model, 
containing  all  SW  applications  dealing  with  pure  avionics 
functions  as  well  as  application  dependent  SW  modules 
for  data  management  and  communication.  Beneath  the  AL 
the  Operating  System  Layer  (OSL)  is  placed,  comprising 
the  operating  system  and  general  SW  modules  for  system 
management  and  communication  purposes.  Within  the 
ASAAC  architecture  model  the  Module  Support  Layer 
(MSL)  is  the  lowest  SW  layer,  closest  to  the  HW.  It  is  a 
cluster  of  HW  related  driver  SW  needed  for  operating  the 
respective  HW.  AL,  OSL  and  MSL  are  coupled  via 
standardised  interfaces  -  Application  to  Operating  System 
Interface  (APOS)  and  Module  to  Operating  System 
Interface  (MOS)  -  according  to  the  ASAAC  layered 
architecture  model.  APOS  and  MOS  are  defined  with  in 
the  ASAAC  standards. 

System  architectures,  designed  in  layers  according  to  the 
ASAAC  model,  imply  a  semi-automatic  configuration  of 
the  HW  and  SW  of  an  avionics  system  by  system  tables, 
so-called  blueprints.  In  these  Blueprints  no  unique  HW 
and  SW  configuration  is  described  but  a  variety  of 
configurations,  which  cover  possible  in  flight  failures  of 
single  HW  or  SW  components.  After  an  in  flight  failure 
has  occurred,  an  in  flight  reconfiguration®  of  the 
remaining  HW  and  SW  components  maybe  necessary.  A 
semiautomatic  writing  of  blueprints  is  supported  by  SW 
tools.  Thereby  system  engineers  are  supported  to  develop 
different  configurations  for  the  HW  and  SW  components 
of  an  avionics  system  with  an  affordable  amount  of  effort. 
These  configurations  have  to  cover  the  failure  free  system 
status  as  well  as  possible  failures  of  HW  and  SW 
components  of  an  avionics  system.  During  operation  of  an 
avionics  system,  the  blueprints  are  loaded  as  data  files  in 
the  HW  components  of  an  avionics  system. 

ASAAC  therefore  not  only  defines  standards  for  the 
design  of  open  system  architectures  for  military  aircraft 
avionics  but  also  investigates  SW  tools  for  the  realisation 
and  implementation  of  ASAAC  standards  respectively 
IMA. 


®  After  an  in  flight  failure  occurred,  a  reconfiguration  becomes 
necessary,  if  avionics  functions  needed  for  aircraft  operation  are  no 
longer  available  via  the  remaining  HW  and  SW  resources.  If  latter  are 
not  sufficient  to  offer  all  avionics  functions  of  a  fully  operable 
avionics  system,  then  avionics  functions  no  longer  needed  for  aircraft 
operation  have  to  be  shut  down.  The  SW  of  avionics  functions 
needed,  then  has  to  be  newly  distributed  onto  the  remaining  HW  by  a 
reconfiguration  of  the  avionics  system. 


Until  ASAAC  conform  HW  and  SW  components  are 
available,  components  offered  on  the  COTS  market  are  an 
adequate  solution.  Then  already  the  next  generation  of 
computer  systems  for  military  aircraft  can  follow  an  open 
system  design.  Simultaneously,  as  discussed  in  chapter  5, 
obsolescence  risks  related  with  such  computer  systems  are 
reduced. 

4.2  COTS 

EADS  MABU  has  designed  a  Universal  Aircraft 
Computer  (UAC)  based  on  COTS  components  as  a  short¬ 
term  available  computer  system  for  mission  critical 
military  aircraft  avionics,  which  has  an  open  system 
architecture.  The  UAC  is  gaining  increasing  recognition 
for  upgrade  programs  of  in  service  military  aircraft,  the 
design  of  an  avionics  system  for  a  new  trainer  aircraft  and 
as  an  answer  to  the  obsolescence  problems  encountered 
with  current  avionics  of  military  aircraft.  Further  more 
severe  cost  restrictions  and  a  shrinking  procurement 
market  for  military  ruggedised  computer  systems  [5]  are 
additional  drivers  for  a  lasting  use  of  COTS  components. 

4.2.1  Central  Design- Aspects  of  COTS  Computer- 
Systems 

The  UAC  is  designed  as  a  multiprocessor  system  for 
mission  critical  avionics  applications.  To  fulfil  this 
requirement,  the  basic  version  of  the  UAC  design 
comprises  a  conduction  cooled  VME  backplane  fitted 
1  ATR  chassis,  in  which  the  following  VME  boards^  are 
integrated: 

•  three  PPC603e  processor  boards,  two  of  them 
enhanced  with  MlLbusl553B  PCI  mezzanine  cards 
(PMC) 

•  one  analog  input  board 

•  one  graphic  board 

With  the  UAC  a  group  of  external  electronic  interfaces 
can  be  served: 

•  RS232 

•  Ethernet 

•  Discretes 

•  Analog  Input 

•  RGB 

•  MILbusl553B 

•  ARINC429 

•  ATM 

•  Fibre  Channel 

These  interfaces  enable  the  UAC  to  be  integrate  into  the 
avionics  of  military  aircraft. 

For  operating  the  UAC,  the  commercially  available 
realtime  operating  system  LynxOS  is  used.  Driver  SW 
fitting  with  the  chosen  HW  components  is  made  available 
by  the  HW  supplier  for  different  operating  systems.  The 
operating  system  has  to  be  configured  according  to  the 
HW  used.  Since  the  operating  system  is  fitted  with  a 
POSIX  interface,  UNIX  compatible  SW  applications  are 
supported  on  the  UAC. 


’  To  be  integrated  into  the  conduction  cooled  ATR  chassis  of  the  UAC, 
boards  have  to  be  fitted  with  wedge-locks  compliant  with  IEEE 
1 101.2  for  mechanical  fixing. 
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The  HW  components  used  for  the  UAC  have  been 
specified  by  the  supplier  as  ruggedised  according  to  MIL- 
STD,  concerning  physicals  loads  the  system  will 
experience  when  operated  in  military  aircraft.  Therefore 
the  HW  can  resist  extreme  temperature  fluctuations, 
moisture,  vibration,  shock,  EMC  etc..  Supplier  delivered 
CoCs  grant,  that  the  components  are  qualified  for  the 
relevant  physical  loads.  Dependent  on  the  CoCs  is  the 
licensing  of  the  UAC  for  use  in  military  aircraft. 

The  basic  configuration  of  the  UAC  described  above  is 
only  one  possible  configuration  of  the  UAC.  However  the 
system  architecture  of  the  UAC  is  fixed,  which  means  the 
UAC  is  a  commercial  VME  based  computer  system 
housed  in  an  ATR  chassis.  This  chassis  then  is  configured 
for  a  particular  application  by  use  of  ruggedised  Double- 
Eurocard®  VME  boards.  Further  the  chosen  chassis  has  to 
have  spare  slots,  in  case  the  integration  of  additional  VME 
boards  becomes  necessary  later  on  due  to  enhanced 
functional  requirements.  External  interfaces  of  the  UAC 
are  selected  according  to  the  avionics  system  the  UAC  is 
planned  to  be  integrated  with.  HW,  OS  and  SW-drivers 
are  procured  via  the  COTS  market.  Although  all  HW 
components  of  the  basic  configuration  of  the  UAC  are 
offered  by  one  supplier,  a  close  coupling  towards  a  single 
supplier  has  not  taken  place. 

Like  with  proprietary  computer  systems,  each  intended 
UAC  configuration  has  to  be  defined  via  requirements  and 
a  specification.  Derivatives  of  already  existing  UAC 
configurations  may  then  be  described  via  amendments  to 
existing  documents.  Therefore  time  savings  related  with 
the  use  of  COTS  components  are  mainly  seen  within  the 
development  phase  of  a  computer  system.  If  fully 
developed  COTS  components  are  deployed  for  the 
configuration  of  computer  systems,  a  development  phase 
as  used  for  proprietary  solutions  will  no  longer  be 
applicable.  However,  the  definition  and  procurement 
phase  can  be  barely  shortened  by  the  use  of  COTS. 
Nevertheless,  the  total  time  needed  to  configure  a  COTS 
computer  system  will  be  less  than  that  needed  for  a 
proprietary  solution.  This  implies  cost  savings  parallel  to 
the  lower  procurement  costs  of  COTS  components.  How 
far  LCC  savings  are  possible  with  COTS  solutions  is  part 
of  an  ongoing  investigation. 

4.2.2  Context  to  Open  Systems 

The  UAC  is  built  up  from  commercially  available  HW, 
OS  and  driver  SW,  coupled  via  well  established  HW  and 
SW  interfaces  and  follows  a  layered  system  architecture 
like  that  stated  for  open  systems  and  AS  A  AC. 

With  VME  as  data-bus  for  inter-board  communication 
and  PCI  as  local  data-bus  for  adding  mezzanine  cards  to 
VME-boards,  well  established  and  therefore  technical 
stable  electronic  interfaces  have  been  chosen  for  the 
architecture  of  the  UAC.  The  stability  of  these  interface 
technologies  becomes  obvious  regarding  the  broad  variety 
of  VME  boards  and  PCI  mezzanine  cards  offered  by  many 


The  geometric  dimensions  of  double  Eurocard  boards  are:  233.35 
[mm]  width  *  160  [mm]  height. 


COTS  suppliers.  American  National  Standards  Institute 
(ANSI),  IEEE  and  VMEbus  International  Trade 
Organisation  (VITA),  are  all  well  known  organisations  for 
technical  standardisation  matters,  that  have  maintained  the 
VME-  and  PCI-  standards.  These  interfaces,  the  geometry 
of  the  chassis  and  the  mechanical  board  fixing  guarantee 
the  exchangeability  of  UAC  components  in  the  long-term. 
Enhancements  of  the  UAC  are  supported  by  free  VME 
slots  on  the  VME  backplane  together  with  free  PCI  slots 
on  integrated  VME  boards. 

Know-how  as  well  as  experience  concerning  interfaces, 
HW,  OS  and  driver  SW  of  the  UAC  are  absolutely 
necessary  when  using  COTS  components.  Only  then  is  it 
possible  to  take  advantage  of  the  modification  and 
extension  potential  inherent  to  the  open  architecture  of  the 
UAC.  Plug-and-Play  features  are  commonly  not 
supported  by  COTS  components.  This  mainly  depends  on 
how  strict  COTS  suppliers  adhere  to  established  interface 
standards  in  the  design  of  their  components.  This  is  also  a 
factor  determining  if  COTS-components  from  different 
suppliers  can  be  mixed,  although  they  are  classified  as 
VME  boards  or  PCI  mezzanine  cards. 

The  open  aspect  of  the  UAC  architecture  has  been 
verified  by  using  it  in  different  projects  with  requirements 
that  could  not  be  fulfilled  with  the  basic  UAC 
configuration  (Figure  4).  Therefore  the  PPC603e  board, 
which  within  the  basic  configuration  is  not  fitted  with  a 
MILbus  1553B  PCI  mezzanine  card,  was  replaced  by  a 
PPC750  processor  board.  Additionally  a  further  PPC750 
board  was  integrated  into  the  ATR  chassis.  Furthermore  a 
mass  memory  board  was  added  to  the  configuration  and 
the  graphics  board  was  removed.  Only  boards  ruggedised 
for  flight  and  delivered  by  the  same  supplier  as  the  basic 
version  of  the  UAC  were  used  for  these  modifications. 
Within  a  another  modification  all  three  PPC603e  boards 
are  replaced  by  PPC750  boards  provided  by  a  different 
supplier.  Since  primarily  designed  for  operation  in  an 
industrial  environment,  these  boards  additionally  can  be 
ruggedised  for  flight  by  the  supplier,  if  this  is  a  customer 
requirement.  Two  of  these  three  PPC750  boards  will  be 
fitted  with  the  MILbus  mezzanine  cards  delivered  by  the 
supplier  of  the  UAC  basic  version. 

5.  OBSOLESCENCE  MANAGEMENT 

Continuously  shorter  development  cycles  within  the  IT 
industry  accelerates  the  obsolescence  of  IT  products,  with 
their  life  cycles  getting  shorter.  Simultaneously  this 
process  is  accompanied  by  shrinking  government  budgets 
for  military  expenses.  Therefor  an  effective  obsolescence 
management  concerning  the  avionics  of  military  aircraft  is 
gaining  lasting  importance.  Concerning  avionics 
computers,  different  kinds  of  obsolescence  risks  have  to 
be  faced; 

•  Already  when  production  of  a  proprietary  avionics 
computer  starts,  some  electronics  parts  needed  may 
no  longer  be  available,  because  they  have  become 
obsolete  since  the  development  phase  of  the  computer 
has  been  completed. 
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•  The  performance  of  aged  proprietary  computers  may 
no  longer  be  sufficient  to  serve  the  enhanced  needs  of 
today’s  avionics  systems.  Since  the  underlying 
technology  of  these  systems  has  not  been  further 
developed,  a  system  upgrade  isn’t  possible. 

•  Components  or  parts  necessary  to  repair  inoperable 
computer  systems  have  become  obsolete  and  are  no 
longer  available  via  the  respective  market  and  spare 
stocks  built  up  by  the  system  operator  have  been  used 
up. 

Therefore  in  recent  years  international  committees  and 
industry  have  discussed  possibilities  for  an  effective 
obsolescence  management  regarding  the  avionics  of 
military  aircraft.  Open  computer  systems  based  on  COTS 
offer  several  approaches  for  an  effective  obsolescence 
management  of  military  aircraft  avionics,  as  discussed  in 
the  following  chapters. 

5.1  COTS  Base 

Computer  components  offered  on  the  COTS  market 
usually  are  available  in  the  short-term.  Therefore  the 
mentioned  obsolescence  risk  due  to  elapsed  time  between 
development  phase  and  production  start  is  not 
encountered  with  COTS.  Obsolescence  risks 
corresponding  with  an  ageing  computer  system  are 
mitigated  by  the  common  adherence  of  COTS 
components  to  commercially  well  established  HW  and 
SW  interface  standards.  Because  of  competition  COTS 
suppliers  are  strongly  interested,  that  their  components  are 
compatible  with  such  standards.  To  stay  in  business  with 
traditional  customers  and  to  gain  new  customers,  suppliers 
depend  on  the  compatibility  of  their  components  with  the 
products  of  other  suppliers  as  well  as  the  upward  and 
downward  compatibility  of  their  own  components. 

5.2  Layered  Model 

SW  applications,  developed  according  to  the  layered 
ASAAC  model,  can  be  ported  onto  different  HW 
configurations  with  a  minimum  amount  of  effort.  Using 
the  ASAAC  standards  allows  for  later  enhancements  and 
modifications  of  the  SW  application  to  be  easy  performed. 
Therefore  a  layered  SW  architecture,  as  propagated  in  the 
context  of  open  systems,  helps  to  reduce  costs,  time  and 
effort  caused  by  HW  and  SW  obsolescence,  thereby 
supporting  an  effective  obsolescence  management. 

5.3  Running  Upgrades 

Computer  systems,  which  experience  short  and  regular 
upgrade  cycles,  will  show  only  little  obsolescence 
between  two  successive  upgrades.  As  a  result,  upgrades  as 
well  as  interim  maintenance  and  repair  efforts  will  be  less 
complex  and  less  costly.  However  if  upgrades  are  widely 
spaced,  a  lasting  obsolescence  of  computer  systems  is 
allowed.  This  will  rise  complexity  and  costs  for  upgrades, 
maintenance  and  repair.  In  the  long-term,  running 
upgrades  will  limit  the  obsolescence  of  computer  systems, 
therefore  being  more  affordable  than  widely  spaced 
upgrades.  Again  the  layered  HW  and  SW  architecture  of 


open  systems  supports  an  effective  obsolescence 
management  when  based  on  running  upgrades. 

5.4  Design  of  Avionics  Systems  by  System  Tables 

A  SW  tool,  which  allows  a  semiautomatic  system 
configuration  by  writing  system  Blueprint  tables  as 
introduced  in  chapter  4.1  ASAAC,  can  also  be  used  for  a 
more  effective  obsolescence  management.  However, 
obsolescence  risks  inherent  to  computer  systems  will  not 
be  mitigated.  A  respective  SW  tool  simplifies  the 
integration  of  HW  and  SW  modifications,  which  have 
become  necessary  due  to  the  obsolescence  of  a  computer 
system.  Developed  for  a  better  and  easier  design  of 
complex  avionics  systems,  such  a  tool  also  serves  an 
effective  obsolescence  management. 

5.5  Life  Time  Buy 

If  a  COTS  supplier  intends  to  stop  support  and  production 
of  a  certain  computer  component,  which  has  become 
obsolete,  he  will  probably  offer  his  customers  a  Life  Time 
Buy  opportunity  for  this  component  [6].  Therefore 
computer  systems  based  on  COTS  components  enable  a 
refinement  of  traditional  obsolescence  management 
strategies  mainly  relying  on  stock  building.  A  customer 
will  no  longer  be  forced  to  determine  and  to  buy  the 
necessary  amount  of  spares,  to  cover  the  whole  life  time 
of  a  computer  system,  which  has  just  been  put  into 
service.  He  can  determine  the  amount  of  spares  needed  for 
maintenance  and  repair  when  offered  a  Life  Time  Buy 
opportunity  by  the  supplier,  and  thereby  avoids  a  costly 
capital  investment  in  stocks.  Furthermore  the  inherent 
uncertainty  about  the  amount  of  spares  needed  will  have 
diminished  at  that  time.  This  alternative  is  adequate  for  an 
effective  obsolescence  management,  especially  if  it 
becomes  obvious,  that  a  COTS  computer  system  despite 
his  open  architecture  will  experience  no  more  upgrades 
till  the  end  of  his  service  life. 

6.  RESUME 

COTS  computer  components,  due  to  their  alignment  to 
commercially  established  international  HW  and  SW 
interface  standards,  contain  a  lasting  potential  to  introduce 
open  computer  systems  into  the  avionics  of  military 
aircraft.  At  the  same  time  these  computer  systems  will  be 
cheaper  and  better  in  performance  then  proprietary 
solutions.  Generally  even  open  COTS  based  computer 
systems  will  not  fit  Plug-and-Play  design  features.  For  the 
configuration  of  open  computer  systems  based  on  COTS 
components  comprehensive  know-how  is  necessary  about 
the  HW  and  SW  used,  as  well  as  about  the  porting  of 
application  SW  on  different  HW  platforms.  Open,  COTS 
based  computer  systems  for  the  avionics  of  military 
aircraft  are  an  effective  approach  towards  IMA  until 
ASAAC  conform  avionics  equipment  is  available.  The 
scope  for  an  effective  obsolescence  management  is 
already  determined  in  the  design  phase  of  a  system.  Open 
COTS  computer  systems  can  help  to  make  this  scope 
given  by  current  technology  as  big  as  possible.  Finally 
however  the  actual  market  request  for  such  systems  will 
determine  the  success  of  this  design  approach. 
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7.  ABBREVIATIONS 

AL  Application  Layer 

ANSI  American  National  Standards  Institute 

API  Application  Program  Interface 

APOS  Application  to  Operating  System  Interface 

ASAAC  Allied  Standard  Avionics  Architecture  Council 
ATR  Air  Transport  Rack 

C4I  Command,  Control,  Communications, 

Computers  and  Intelligence 
CoC  Certificate  of  Conformance 

COTS  Commercial  Off  The  Shelf 

cPCI  Compact  PCI 

DASS  Defensive  Aid  Subsystem 

DoD  Department  of  Defense 

EMC  Electromagnetic  Compatibility 

GOA  Generic  Open  Architecture 

HW  Hardware 

IEEE  Institute  of  Electrical  and  Electronic  Engineers 

IMA  Integrated  Modular  Avionics 

I/O  Input  /  Output 

IT  Information  Technology 

JTA  Joint  Technical  Architecture 

LCC  Life  Cycle  Costs 

LRU  Line  Replaceable  Unit 

MABU  Military  Aircraft  Business  Unit 

MOS  Module  to  Operating  System  Interface 

MSL  Module  Support  Layer 

OEM  Original  Equipment  Manufacturer 

OS  Operating  System 

OS-JTE  Open  Systems  Joint  Task  Eorce 

OSL  Operating  System  Layer 

PCI  Peripheral  Component  Interconnect 

PMC  PCI  Mezzanine  Card 

POSIX  Portable  Operating  System  Interface 

PPC  Power  Processor 

SBC  Single  Board  Computer 

STANAG  (NATO)  Standardisation  Agreements 

SW  Software 

TAEIM  Technical  Architecture  Eramework  for 

Information  Management 
UAC  Universal  Aircraft  Computer 

VITA  VMEbus  International  Trade  Organisation 

VME  Versatile  Module  Europe 
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9.  FIGURES 


Figure  1 ;  Avionics  system  EF2000 
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Figure  2:  OS-JTF  Electronics  Reference  Model 
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Figure  3;  ASAAC  model  for  layered  system  architectures 


Avionics  Application  A 


□  1  ATR-ChassIs  with 
Power  Supply 

□  VMEbusM 
Backplane 


Configuration: 

□  3  PowerPC  603e  Boards 

□  2  MILBus1S53B  PCI  Mezzanine 
Cards 

□  1  Analog  Input  Board 

□  1  Graphik  Board 

□  3  Spare  Slots 


Avionics  Application  B 


Configuration; 

□  2  PowerPC  603e  Boards 

□  2  PowerPC  750  Boards 

□  2  MILBus1553B  PCI  Mezzanine 
Cards 

□  1  Analog  Input  Board 

□  1  Permanentspeicher  Board 

□  1  Spare  Slot 


Avionics  Application  C 


IT 


□  LynxOS  Real-Time  0/S 

Lynx 


Configuration: 

□  3  PowerPC  750  Boards 

□  2  MILBus1553B  PCI  Mezzanine 
Cards 


□  5  Spare  Slots 


UAC 

Universal  Aircraft  Computer 


Figure  4;  COTS  Computer  with  an  open  system  architecture 
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1.  INTRODUCTION 

Obsolescence  of  electromechanical  instruments  and 
navigation  sensors  is  one  of  the  main  reasons  for  new 
avionics  development  in  military  training  aircraft 
upgrade  programs. 

The  growing  requirements  for  advanced  trainers  in  the 
role  of  lead-in-fighter  aircraft  push  the  development  of 
integrated  avionics  system  where  cockpit  displays, 
mission  computer,  solid-state  navigation  sensors, 
communication  transceivers  and  flight  data  recorders 
are  extensively  employed. 

The  use  of  COTS  (Commercial  Of  The  Shelf)  solutions 
allows  to  mitigate  components  obsolescence  and  to 
meet  the  new  operational  requirements  at  an  affordable 
cost  with  reasonable  development  risk. 

The  purpose  of  this  paper  is  to  provide  an  overview  of 
how  these  concepts  have  been  applied  in  the 
development  of  an  innovative,  modular  and  reliable 
avionics  system. 

The  latest  version  of  the  proven  MB-339  twin  seat  jet 
powered  advanced  trainer  employs  a  modern  state-of- 
the-art  avionics  architecture  based  on  standard  bus 
interface  (i.e.,  MIL-STD-1553  and  ARINC  429), 
capable  to  easily  integrate  COTS  equipment. 

The  system  exhibits  a  full  glass  cockpit  with  three 
identical  and  interchangeable  Multifunction  Displays, 
Head-up  Display  and  independent  get-home 
instrumentation  for  back-up  flight  data  presentation:  all 
the  cockpit  displays  use  COTS  active  matrix  full  colour 
high  resolution  LCD’s. 

COTS  solutions  are  applied  at  hardware  level  in 
computer  processing,  interface  and  memory  devices, 
providing  state-of-the-art  high  performance  digital 
technology  solutions. 

Radio  navigation  equipment,  air  data  computer  and  an 
embedded  inertial-GPS  platform  are  employed  as 
proven,  off-the-shelf  and  fully  qualified  military 
equipment. 

The  paper  highlights  the  advantages  gained  by  the 
employment  of  COTS  solutions  in  a  modern,  flexible 
and  expandable  avionics  architecture.  In  the  paper,  the 
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equipment  is  deliberately  described  in  general  terms, 
omitting  any  manufacturer  reference. 

2.  MB-339CD  AVIONICS 
2.1  General 

The  Aermacchi  MB-339CD  aircraft  (Fig.  1)  is  a  single 
engine,  tandem  seat  jet  trainer  designed  for  advanced 
and  lead-in-fighter  training  in  order  to  allow  pilot’s 
conversion  to  the  latest  generation  of  operational 
aircraft. 


Figure  1.  MB-339CD  Aircraft. 


The  aircraft  was  designed,  developed  and  tested  in  the 
middle  of  the  90’ s  and  is  currently  in  service  with  the 
Italian  Air  Force.  The  first  flight  was  performed  on 
April  1996  while  the  Final  Operational  Capability 
(FOC)  was  reached  on  October  1998;  an  improved 
version  of  the  aircraft,  with  additional  capabilities,  will 
be  delivered  on  December  2001. 

The  MB-339CD  aircraft  design  is  based  on  the  proven 
airframe  structure,  engine  and  general  systems  (i.e., 
fuel,  hydraulic,  electrical,  flight  controls  and  landing 
gear)  fully  qualified  on  the  MB-339A  model,  while  a 
new  avionics  system  is  fitted  in  order  to  enable  training 
with  modern  operational  techniques,  including  use  of 
an  Head-up  Display  (HUD),  Hands  On  Throttle  and 
Stick  (HOTAS),  and  Multifunction  Displays  (MFD’s), 
enhancing  mission  effectiveness  and  aircraft 
survivability  (Fig.  2). 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
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Thanks  to  the  avionics  updating,  the  MB-339CD  fills 
the  gap  between  traditional  trainers  and  new  combat 
aircraft. 

The  MB-339CD  avionics  is  based  on  a  modern 
architecture  using  digital  data  buses  as  mean  of  on¬ 
board  information  exchange  between  sensors, 
computers  and  cockpit  displays. 


Fig.  2.  MB-339CD  Cockpit  Layout. 


The  installed  navigation  sensors,  processing  equipment 
and  electronic  displays  not  only  exhibit  high 
performances  in  terms  of  accuracy,  growth  potential 
and  man-machine  interface,  but  also  show  improved 
reliability  reducing  in  service  maintenance  costs. 

This  section  provides  a  description  of  the  aircraft 
sensors,  computers,  controls  and  displays,  merged  in  a 
fully  integrated  Navigation/ Attack  system. 

2.2  Avionics  Architecture 

The  main  components  of  the  MB-339CD  avionics  are 
the  following: 

Sensors _ 

Embedded  GPS-Inertial  (EGI)  platform 

Air  Data  Computer  with  associated  Pitot/Static 

ports  and  Total  Temperature  Sensor  (TTS) 

Angle  of  Attack  and  Angle  of  Sideslip  transducers 
Radio  Navigation  systems  including  VOR/ILS, 
TACAN  and  ADE 


Radar  Altimeter 

Computers _ 

Mission  Processor  (MP) 

Data  Transfer  System  with  embedded  Digital  Map 
Generator  (DMG) 

Engine  Instrument  and  Crew  Alerting  System 
(EICAS)  Data  Acquisition  Box  (EDAB) 

-  Stores  Management  System  (SMS) 

Recorders _ 

Elight  Data  Recorder  (EDR)  with  Crash 
Survivable  Memory  Unit  (CSMU) 

-  Video  Cassette  Recorder  (VCR) 

Controls  and  Displays _ 

Head-up  Displays  (HUD)  with  embedded  Data 
Entry  Panel  (DEP) 

-  Multifunction  Displays  (MED) 

HOT  AS  controls 

Heading/Course  and  Baro/ Altitude  rotary  controls 

These  components  are  interconnected,  directly  or 
through  adequate  interfaces,  by  a  MIL-STD-1553  dual 
redundant  data  bus  called  Avionics  Bus  (Eig.  3). 

The  Avionics  Bus  is  mainly  controlled  by  the  Mission 
Processor  which  acts  as  the  primary  Bus  Controller;  in 
the  event  of  a  critical  Mission  Processor  failure,  the 
EGI  system  is  able  to  provide  back-up  bus  controller 
capability  assuring  complete  redundancy. 

Several  equipment  such  as  EDAB,  MP,  EDR  include 
analog,  discrete,  video  and  digital  interfaces  in  order  to 
allow  the  acquisition  of  the  parameters  provided  by 
aircraft  devices  (general  systems  transducers,  HOTAS 
and  rotary  controls)  and  to  allow  the  integration  of 
equipment  which  have  non- 1553  interface. 

The  system  architecture  is  characterised  by  a 
distributed  processing  capability  which  allows  a 
rationale  and  simple  allocation  of  the  system  functions: 
the  EGI  and  ADC  provide  the  navigation  parameters 
directly  used  by  the  primary  flight  displays,  the  EDAB 
is  based  on  two  fully  redundant  and  independent 
electronic  circuits  capable  to  provide  in  digital  form  the 
parameters  acquired  by  the  general  systems  and  the 
MED  include  1553  interface  and  graphic  processing,  to 
autonomously  generate  the  symbology  based  on  the 
information  available  on  the  Avionics  Bus. 

With  these  important  characteristics  the  required 
system  redundancy  is  obtained  without  duplication  of 
the  central  processing  and  symbology  generation.  The 
overall  result  is  a  simple  and  reliable  architecture. 

The  high  level  of  flexibility  of  the  avionics  system, 
coupled  with  the  considerable  computing  capability  of 
the  installed  computers,  allows  for  a  remarkable  growth 
potential  such  as:  self-protection  systems  (including  a 
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Radar  Warning  Receiver,  a  Chaff  and  Flares  Dispenser 
and  a  pod  mounted  active  ECM),  a  Forward  Looking 
IR  (FLIR)  system,  a  pod  mounted  Reconnaissance 


(RECCE)  system,  a  rangless  GPS-based  Air  Combat 
Manoeuvring  Instrumentation  (ACMI)  system,  and 
embedded  sensors  (Radar/RWR)  simulation  capability. 


Figure  3.  MB-339CD  Avionics  Architecture. 


2.3  Sensors 

The  Embedded  GPS  Inertial  (EGI)  platform  is  a  self- 
contained  unit  consisting  of  three  Ring  Laser  Gyros, 
three  solid-state  accelerometers  and  associated 
electronics  capable  to  guarantee  accurate  inertial 
navigation;  embedded  in  the  EGI  is  a  tightly  coupled 
GPS  receiver  module  with  6  channels  and  P(Y)  code 
capability  which  uses  pseudo-range  and  pseudo-range 
rate  satellite  data. 

The  EGI  supplies  the  navigation/attack  system  with 
accurate  information  related  to  the  aircraft  attitude, 
position,  velocities  and  accelerations;  roll  and  pitch 
angles,  roll,  pitch  and  yaw  rates,  magnetic  and  true 
heading,  ground  speed,  aircraft  body  axes  speeds  and 
accelerations,  present  position,  wind  data,  steerpoint 
data,  and  time  data  referred  to  the  GPS. 

The  demonstrated  EGI  performances  are  the  following: 

Position  accuracy  (CEP)  pure  inertial:  <  0.8  NM/h; 

-  Position  accuracy  (CEP)  blended:  <  100  m  (SPS); 
Velocity  accuracy  (rms)  pure  inertial:  <1.0  m/s; 
Velocity  accuracy  (rms)  blended:  <  0.03  m/s. 

The  provided  data  are  always  the  best  available 
solution  obtained  by  filtering  the  inertial  and  GPS  data 


through  a  Kalman  filter.  This  allows  reduction  of  the 
Mission  Processor  workload. 

The  GPS  receiver  can  work  in  the  Standard  Positioning 
Service  or  in  the  Precise  Positioning  Service  mode. 
Thanks  to  the  GPS  integration,  the  EGI  can  be 
commanded  to  align  on  ground  and  in  flight  with  a 
nominal  alignment  time  of  4  minutes. 

The  Air  Data  Computer  (ADC)  with  associated 
Pitot/Static  ports  and  Total  Temperature  Sensor  (TTS) 
includes  extremely  accurate  pneumatic  transducers  and, 
thanks  to  a  powerful  computer,  is  able  to  provide  in 
digital  form  the  most  important  air  data  parameters; 
total  and  static  pressure,  altitude,  vertical  velocity,  baro 
corrected  altitude,  indicated  and  true  airspeed,  Mach 
number,  maximum  allowable  airspeed,  and  outside 
total  temperature. 

The  ADC  guarantees  the  following  performances; 

Pressure  Altitude  accuracy  ±  7  ft  (sea  level) 
Indicated  Airspeed  accuracy  ±  0.5  kts  @  300  kts 
Temperature  accuracy  ±  0.5°C 

The  unit  design  is  characterised  by  ultra  compact  and 
light  box  (<  0.9  kg)  and  extremely  reduced  power 
requirements  (6  W  @28  Vdc). 
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The  Angle  of  Attack  and  Angle  of  Sideslip 

transducers  are  directly  connected  to  the  Mission 
Processor,  which  includes  the  Analog  to  Digital 
converter  to  acquire  and  convert  the  parameters. 

The  Radio  Navigation  system  is  based  on  three 
equipment;  VOR/ILS/MB,  TACAN  and  ADF. 

The  VOR/ILS/MB  unit  is  a  fully  digital  VO/LOC, 
Glideslope  (GS)  and  Marker  Beacon  receiver, 
providing  both  Commercial  Standard  Digital  Bus 
(CSDB)  and  ARINC  429  interfaces.  The 
VOR/ILS/MB  operates  with  a  frequency  control  panel 
and  three  antennas;  it  uses  digital  techniques  to  read 
serial  input  data  provided  by  the  frequency  control 
panel,  to  compute  navigation  situation  and  to  generate 
serial  data  outputs  including  VOR  Bearing,  ILS  Lateral 
and  Vertical  deviations,  MB  annunciators.  The  unit 
design  guarantees  FM  immunity  and  software 
verification  according  to  DO-178A,  lev.  1. 

The  TACAN  receiver-transmitter  is  a  microprocessor- 
controlled  unit  operating  with  two  antennas  and  remote 
control  panel.  It  outputs  bearing,  slant  range,  time  to 
station,  range  rate  and  Morse  code  identification  from  a 
standard  TACAN  ground  station.  The  equipment 
provides  also  an  air-to-air  operational  mode  for  aircraft 
ranging,  bearing  and  identification  reception  from 
equipped  aircraft;  it  includes  the  complete  provision  for 
DME-P  function. 

The  units  operates  with  all  126  X  channels  and  126  Y 
channels  providing  an  RF  peak  power  of  750  watts. 

The  ADF  (provision)  is  a  microprocessor  controlled 
receiver  providing  relative  bearing  between  aircraft  and 
the  selected  ground  station.  The  receiver  operates  with 
a  frequency  control  panel  and  a  dedicated  antenna.  The 
output  data  is  provided  through  a  digital  ARlNC-429 
data  bus. 

The  Radar  Altimeter  (Radalt)  is  a  solid-state  system 
performing  aircraft  height  measurements  with  the 
following  characteristics: 

Height  accuracy  ±  3  ft 

-  Altitude  range  0  to  5000  ft 

-  Attitude  (pitch/roll)  range  ±45° 

It  generates  analog  signals  acquired  and  processed  by 
the  Mission  Processor  to  provide  height  digital  data  to 
be  displayed  on  MFD  and  HUD;  the  output  data  are 
also  used  by  the  MP  to  provide  a  low-altitude  warning 
through  the  Audio  Warning  Generator. 

2.4  Processing  Equipment 

The  Mission  Processor  is  the  heart  of  the  avionics 
system  since  it  performs  essential  functions  like 
Avionics  Bus  control.  Head-up  Display  symbology 
generation,  HOTAS  interface  and  Navigation/ Attack 
computation. 


The  equipment  is  a  high  performance,  12  slots,  full 
military  qualified  computer;  it  is  based  on  a  powerful 
RISC  CPU  and  characterised  by  a  modular  design 
exhibiting  the  following  main  features: 

-  CPU  RISC  3081,  12  MIPS; 

-  Memory  2  Mbytes  RAM,  8  Mbytes 

FLASH,  128  Kbytes 
EEPROM; 

-  Interfaces  MIL  1553,  ARINC  429, 

analog,  discrete,  video; 
Application  Software  ADA  language. 

The  full  development  phase  of  the  Operational  Elight 
Programme  (OEP),  including  software  specifications, 
coding,  verification  and  validation,  has  been  performed 
by  Aermacchi,  assuring  a  complete  in-house 
management  capability  of  the  avionics  system. 

Under  OEP  control,  the  MP  is  capable  to  perform  the 
following  functions: 

-  primary  1553  bus  controller; 

HUD  symbol  generation; 

HUD  Data  Entry  Panel  interface; 

-  ARINC  429  interface  for  VOR/ILS/MB  and  ADE 
receivers; 

analog  and  discrete  interface  to  Radalt,  HOTAS, 
Angle  of  Attack  and  Sideslip  transducers; 
video  interface  and  switching  for  HUD  Video 
Camera,  MED's  and  Video  Tape  Recorder; 
management  of  control  inputs  from  MED's,  HOTAS 
and  Data  Entry  Panel; 

navigation  computation  including  data  base 
management; 

flight  director  and  altitude  alerter  processing; 
weapon  aiming  computation. 

The  Data  Transfer  System,  directly  connected  to  the 
Avionics  Bus,  allows  to  update  the  mission  data  and  to 
record  the  flight  history  data  used  for  mission 
debriefing  purposes.  The  DTS  also  includes  the  Digital 
Map  Generator,  which  provides  raster  and  vector 
colour  moving  map  capability. 

The  equipment  consists  of  a  receptacle  unit  and  a 
removable  cartridge,  reprogrammable  on  ground  using 
a  Mission  Planning  and  Debriefing  Station  (MPDS) 
based  on  a  Personal  Computer. 

Key  feature  of  the  equipment  is  that  the  mass  memory 
required  by  both  cartographic  files  and  mission  data  is 
fitted  in  the  cartridge,  allowing  direct  access  by  the 
map  generator  and  immediate  replacement  by  the  pilot. 
The  unit  output  is  an  RGB  video  signal  directly  driving 
the  Multifunction  Displays  through  the  Mission 
Processor,  while  the  cartridge  uses  solid  state  memory 
devices  with  expansible  memory  capacity:  the  present 
configuration  is  1  Gbyte  Plash  covering  1 .000.000  km^ 
(LIOOK)  map  data. 

The  in-flight  available  functions  include: 

-  heading-up  or  north-up  orientation 
scale  and  zoom  selection 
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scrolling,  freeze  and  declutter  capabilities 

DTED  information  management  including  safety 

height  indication 

navigation  overlay  management 

tactical  overlay  management 

The  Engine  Instrument  and  Crew  Alerting  System 
(EICAS)  Data  Acquisition  Box  (EDAB)  is  the  main 
interface  between  the  aircraft  general  systems  and 
avionics.  It  acquires,  computes  and  transmits  in  digital 
form  all  the  parameters  to  be  presented  on  the  cockpit 
displays,  relevant  to: 

Engine  RPM,  Jet  Pipe  Temperature,  Oil 
Pressure,  Euel  Plow 
Puel  tanks  fuel  quantity 

Hydraulic  main  and  emergency  pressure 

Electric  generators  load 

Anti-ice  heaters  status 

In  addition,  the  EDAB  processes  all  the  information 
needed  to  produce  visual  caution  indication  displayed 
on  the  MPD's  and  activates  the  relevant  aural  messages 
provided  by  the  Audio  Warning  Generator. 

The  equipment  is  characterised  by  a  fully  redundant 
architecture:  two  independent  sections  performs  all  the 
above  mentioned  functions  assuring  that  no  single 
failure  leads  to  the  loss  of  the  relevant  indication.  All 
electronic  circuits  and  devices,  starting  from  the 
anolog/discrete  input  to  the  1553  transceiver,  are 
duplicated  providing  high  reliability  and  fault  tolerant 
operation. 

The  Stores  Management  System  is  fully  integrated  in 
the  avionics  system  using  the  MED  as  the  main  pilot 
interface  for  display  and  selection  of  the  stores  carried 
under  the  wings.  In  addition  a  weapon  inventory  panel 
is  provided  to  the  ground  crew  in  order  to  enter  the 
armament  stores  configuration  and  to  check  system 
serviceability.  The  system  includes  independent  circuits 
for  stores  release/launching/firing  and  emergency 
jettison  operations  and,  due  to  the  trainer  role  of  the 
aircraft,  its  hardware  design  is  optimised  to  reach  the 
maximum  level  of  operational  safety. 

The  SMS  allows  the  pilot  to  operate  in  the  following 
modes: 

Continuously  Computed  Impact  Point; 

Continuously  Computed  Release  Point; 

Lead  computed  Optical  Sight; 

Continuously  Computed  Impact  Line; 

Air-to-Air  Missile; 

Dogfight. 


Although  light  and  compact  units  are  installed  in  the 
aircraft,  the  SMS  exhibits  a  wide  weapons  and  external 
load  capability  as  shown  in  Eig.  4. 

2.5  Recording  Equipment 

The  recording  system  collects  all  the  information  useful 
for  pilot  mission  debriefing,  maintenance  trouble 
shooting  and,  in  case  of  accident,  reconstruction  of  the 
last  period  of  flight.  The  system  includes:  a  Video 
Recorder,  a  Elight  Data  Recorder  and  an  Airborne 
Strain  Counter. 

The  Video  Tape  Recorder  (VTR)  records,  according 
to  pilot  selection,  the  images  displayed  on  one  the  front 
cockpit  MED's  or  the  HUD  symbology  superimposed 
on  the  external  world  as  seen  by  the  HUD  Video 
Camera.  In  addition  to  the  colour  images,  the  VTR 
records  the  communications  between  the  two  pilots  and 
between  the  aircraft  and  the  ground  stations. 

The  VTR  uses  standard  Hi-8mm  cassette  providing 
access  to  commercially  available  playback  units  and 
videocassettes. 

The  Flight  Data  Recorder  (EDR)  system  includes  a 
Signal  Acquisition  Unit  (SAU)  and  a  Crash  Survivable 
Memory  Unit  (CSMU),  and  is  used  for  maintenance 
and  post-accident  analysis  purposes. 

The  SAU  is  capable  of  receiving  a  combination  of 
analog,  discrete  and  digital  (1153)  parameters  which 
are  converted,  compressed  and  stored  in  the  embedded 
memory  unit;  the  same  parameters  are  transmitted  to 
the  CSMU  where  they  are  stored  in  a  solid-state,  non¬ 
volatile  and  protected  memory. 
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The  CSMU  is  designed  to  withstand  stringent  mishap 
conditions  including  fire  temperature,  mechanical 
shock  and  penetration. 

All  the  data  collected  by  the  FDR  are  stored  at  lower 
sample  rate  in  the  cartridge  of  the  Data  Transfer 
System  allowing  immediate  data  availability  for 
mission  debriefing  and  maintenance. 

The  Airborne  Strain  Counter  allows  structural 
elements  monitoring  in  order  to  determine  the  fatigue 
life  of  the  airframe  under  real  usage. 

The  microprocessor  controlled  equipment  features  the 
acquisition  of  seven  strain  gauges  fitted  in  the  most 
significant  points  of  the  aircraft  structure  and  of  an 
accelerometer  for  data  correlation  to  the  aircraft 
manoeuvres;  the  processed  data  are  stored  in  non¬ 
volatile  matrix  memory,  downloadable  on  ground  using 
a  PC  based  ground  support  equipment  for  post¬ 
processing  analysis. 


2.6  Cockpit  Controls  and  Displays 

The  MB-339CD  man-machine  interface  philosophy  is 
based  on  two  identical  cockpits  (Fig.  2)  in  order  to 
allow  complete  monitoring  by  the  rear  seat  instructor; 
each  cockpit  includes  an  Head-up  Display  and  three 
identical  and  interchangeable  Multifunction  Displays 
capable  to  provide  all  the  available  formats  under 
pilot’s  selection.  The  rear  cockpit  MFD's  can  operate 
in  independent  or  mimic  mode  to  enhance  the  student 
monitoring  by  the  instructor.  In  the  event  of  integrated 
avionics  system  failure,  a  complete  set  of  stand-by 
instruments  is  provided  in  order  to  guarantee  a  get- 
home  recovery  in  safe  conditions;  it  includes:  Attitude 
indicator.  Magnetic  Compass,  Mach-anemometer, 
Altimeter,  Vertical  Velocity  indicator. 

The  avionics  controls  are  fitted  mainly  in  the 
instrument  panel  for  up-front  operation:  they  are  based 
on  MFD  softkeys  and  Data  Entry  Panel  keyboard.  The 
HOT  AS  concept  is  extensively  employed,  providing  a 
configuration  representative  of  an  actual  fighter 
aircraft. 


provide  as  output  a  video  signal  of  the  displayed  format 
for  recording. 


The  MFD  main  characteristics  are  the  following: 


Display  area 
Display  resolution 
Brightness 
Contrast 
Grey  scale 
Viewing  angle 

-  CPU 

-  Memory 


5.1  X  3.9  inches 
640  X  480  pixels 
>  500  CD/m2 
>5.5  :  1 
64 

±  30°  horiz.,  0  to  30°  vert. 
Motorola  MC68332 
1.5  Mbytes  FLASH,  1 
Mbyte  RAM,  64  Kbytes 
EEPROM 


On  the  bezel  of  the  MED  a  group  of  16  softkeys  are 
fitted:  2  softkeys  on  the  top  allow  presentation  of  the 
Menu  selections  and  display  brightness/contrast 
control,  6  softkeys  on  the  bottom  are  used  to  select  the 
requested  format  and  8  softkeys  on  the  lateral  sides 
provide  pilot’s  selection  according  to  the  displayed 
format. 

Presentation  of  the  requested  information  is  obtained 
through  12  main  formats:  the  first  six  show  data  related 
to  flight  condition  while  the  others  provide  the  pilot 
with  system  status,  check  list  and  special  information 
or  procedure.  The  available  main  formats  are:  ADI 
(Attitude  and  Directional  Indicator),  HSI  (Horizontal 
Situation  Indicator),  MAP,  SMS  (Stores  Management 
System),  SYS  (information  on  general  systems),  SP 
(Steerpoint  list),  IN/GPS  (inertial  platform  alignment 
and  status),  STATUS  (avionics  equipment  status). 
Checklist,  MARK,  TVC  (HUD  Video  Camera),  RWR 
(Radar  Warning  Receiver). 

The  HOTAS  configuration  is  derived  from  P-16 
throttle  and  stick.  The  rotary  controls  are  located  in 
two  separated  control  panels:  the  first,  fitted  below  the 
central  MED,  provide  the  Heading  (HDG)  and  Course 
(CRS)  set  parameters  while  the  second,  installed  on  the 
right  side  of  the  instrument  panel,  allow  the  selection  of 
Barometric  Pressure  set  (BARO)  and  Altitude  (ALT) 
for  altitude  alerter  function. 


The  Head-up  Display  is  composed  by  a  Pilot  Display 
Unit  and  a  Data  Entry  Panel.  The  Pilot  Display  Unit 
uses  dual-flay  holographic  combiners  exhibiting 
excellent  visibility  also  from  the  rear  seat;  it  is  a  raster 
display  whose  navigation  and  attack  symbology  is 
generated  by  the  Mission  Processor. 

The  Multifunction  Displays  are  “smart”  active  matrix 
full  colour  liquid  crystal  displays.  They  are  capable  to 
provide  the  displayed  image  using  both  1553  data 
words  or  external  video  signals:  graphic  on  video 
capability  is  also  foreseen.  The  equipment  includes 
1553  interface,  CPU,  graphic  processor  with  anti¬ 
aliasing  capability,  video  interface  and  is  able  to 


All  the  rotary  controls  are  implemented  through 
incremental  Gray  encoders  providing  discrete  signals 
for  processing  in  the  EDAB. 


3.  COTS  INTEGRATION 
3.1  General 

The  new  avionics  system  development  had  the  main 
purpose  to  provide  the  basic  trainer  aircraft  with  lead- 
in-fighter  improved  capability  within  specific 
constraints  in  terms  defined  development  cycle  and 
fixed  budget. 
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The  new  operational  requirements  pushed  the 
development  of  an  integrated  avionics  system,  in  which 
sharing  of  resources  and  information  between 
subsystems  became  dominant.  This  characteristic 
resulted  in  improved  performance  and  reliability,  whit 
reduced  size,  weight,  power  and  costs. 

To  shorten  development  cycle  and  reduce  recurring 
costs,  several  Commercial-Off-The-Shelf  (COTS) 
solutions  were  investigated  and  adopted  at  three 
development  levels:  avionics  system  design,  equipment 
selection  and  components  employment. 

COTS  integration  in  a  military  application  is  not  an 
easy  task  due  to  the  typical  military  requirements:  harsh 
environments,  maximum  performance  in  minimum 
weight,  volume  and  power  envelope,  fault  tolerance 
and  long  term  supportability. 

Where  COTS  solutions  result  unpractical,  the  reuse  of 
existing  military  units  allows  to  mitigate  the 
obsolescence  problem,  while  implementation  of 
functions  moving  from  hardware  to  computer  software 
is  extensively  applied. 

The  purpose  of  this  section  is  to  provide  a  general 
overview  of  COTS  integration  through  several 
examples  taken  by  the  MB-339CD  avionics  system. 


3.2  Avionics  System  Design 

In  the  MB-339CD  avionics  architecture  the  transfer  of 
information  from  sensors  to  displays  and  from  remote 
controls  to  transceivers  is  completely  digital. 

An  essential  feature  for  COTS  integration  in  the  MB- 
339CD  aircraft  was  the  employment  of  a  widely  used, 
non-proprietary  standards  and  protocols  (i.e.,  not 
forcing  to  use  well  defined  interfaces  for  the  electronic 
equipment). 

In  order  to  provide  high  flexibility  in  equipment 
selection,  several  types  of  standards  were  adopted: 

MIL-STD-1553B  is  applicable  to  the  main  avionics 
data  bus; 

ARINC-429  is  used  to  interface  several  navigation 
equipment  like  VOR/ILS  and  ADF; 

EIA  Standard  RS-422  allows  the  point-to-point  data 
transfer  from  SAU  to  CSMU; 

EIA  Standard  RS-485  is  used  to  multiplexing  the 
information  between  control  panels,  transceivers/ 
transponder  and  remote  display  units. 

Thanks  to  the  implemented  protocols,  the  industry 
standard  RS-485  reached  performances  equivalent  to 
MIL-STD-1553B  at  lower  hardware  cost. 

Specific  functions,  which  in  the  past  required  dedicated 
hardware  resources,  were  implemented  via  software. 
Some  examples  of  these  functions  are  listed  below: 


the  Elight  Director,  that  was  originally  a  stand-alone 
analog  computer,  was  replaced  by  a  software 
module  running  in  the  Mission  Processor; 
navigation  sources  and  modes  selection,  which 
previously  requested  dedicated  cockpit  control 
panels,  were  provided  by  the  MED’s  softkeys 
through  format  dependent  labels; 

weapon  selection  and  monitoring,  originally 
implemented  through  a  dedicated  armament  control 
panel,  was  provided  by  the  SMS  format  in  the 
Multifunction  Display; 

specific  devices  like  altitude/airspeed  switches  or 
dedicated  engine  throttle  position  microswitches 
were  replaced  by  software  controlled  functions 
using  shared  information. 

Eurthermore,  the  MB-339CD  avionics  architecture 
allows  for  future  implementation  of  new  functions, 
simplified  by  the  software  on-board  loading  capability 
of  the  main  avionics  equipment  (i.e.,  MP,  MED,  EGI 
and  EDAB). 


3.3  Equipment 

One  of  the  driving  criteria  in  the  selection  of  the 
equipment  integrated  in  the  aircraft  was  the  use  of 
COTS  units  and,  when  this  aim  did  not  allow  to  comply 
with  the  operational  requirements  or  military 
environmental  constraints,  the  reuse  of  existing  military 
off-the-shelf  equipment.  The  development  of 
customised  equipment  was  therefore  limited  to  those 
applications  that  required  specific  aircraft-dependent 
interfaces  or  with  particular  space  constraints. 

Customisation  of  existing  equipment  became  a  possible 
solution  thanks  to  the  capability  of  autonomously 
developing  embedded  application  software  modules, 
capable  to  meet  system  integration  requirements. 

Examples  of  COTS  equipment  included  the 
VOR/ILS/MB  navigation  receiver  and  the  ADE:  they 
were  general  aviation  units  that  were  integrated  using 
ARINC-429  interface  in  the  Mission  Processor 
(installed  in  the  aircraft  with  specifically  designed 
mounting  trays  to  cover  the  vibration  envelope). 

The  areas  where  reuse  of  existing  units  have  been 
applied,  are  the  following: 

-  Navigation  sensors  like  TACAN,  Air  Data 
Computer  and  Radar  Altimeter; 

Central  processing  equipment  as  the  Mission 
Processor  and  the  Data  Transfer  System/Digital 
Map  Generator; 

Recording  units  like  Video  Recorder; 

Cockpit  displays,  including  HUD  and  MED. 
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The  systems  customised  by  application  software  were 
the  EGI,  the  MP  and  the  FDR;  the  EGI  and  the  MP 
were  controlled  by  an  operational  software  specifically 
developed  for  the  avionics  system,  while  the  FDR 
software  was  updated  to  meet  the  MB-339CD 
application-dependent  interface  requirements. 


3.4  Components 

At  hardware  level,  the  MB-339CD  avionics  showed 
that  the  most  important  goals  of  a  military  aircraft 
development  program  (i.e.,  growth  potential  of 
computing  resources  and  reduction  of  size,  weight  and 
power),  are  conveniently  achieved  by  employing 
electronic  components  and  circuits  derived  by 
commercial  and  industrial  applications. 

COTS  components  were  selected  on  the  basis  of 
technical  suitability  for  the  specific  application,  such  as 
component  temperature  range,  power  and  voltage 
rating.  Furthermore,  the  components  performance  and 
reliability  were  continuously  monitored  through 
feedback  to  equipment  manufacturers. 

Several  COTS  component  applications  were  adopted 
for  the  MB-339CD  avionics  system.  These  are  briefly 
described  below: 

all  the  equipment  connected  to  the  MIL-STD-1553 
data  bus  used  the  same  off-the-shelf  bus  transceiver 
chip  in  a  configuration  capable  to  cover  both 
Remote  Terminal  and  Bus  Controller  functions; 

all  the  CPUs  embedded  in  the  avionics  units  were 
COTS  components  with  extended  temperature 
range;  no  MIF-STD-1750  CPU  was  employed 
while  a  wide  range  of  industrial  CPU  were  used 
including:  Motorola  microcontroller  68332,  Intel 
microprocessors  80960,  80C186,  80C196  and 
80C51,  Texas  Instrument  digital  signal  processor 
TMS  320C3X; 

the  removable  cartridge  of  the  DTS  included  COTS 
solid  state  Flash  memory  with  PCMCIA  interface; 

the  active  matrix  colour  liquid  crystal  display  of  the 
MFD  was  a  COTS  component  exhibiting  full 
compliance  with  military  requirements  thanks  to  the 
ruggedized  design  process; 

the  incremental  Gray  encoders  used  for  the  rotary 
cockpit  controls  were  COTS  components  selected 
on  the  basis  of  resolution,  power  supply  and 
reliability  requirements  compliance. 


3.5  Test  and  Evaluation 

COTS  technology  was  applied  not  only  to  the  on-board 
systems  but  also  to  the  test,  verification  and  evaluation 
tools  including  laboratory  test  equipment,  avionics  Rig 
and  Flight  Test  Instrumentation. 

In  order  to  mitigate  the  obsolescence  risk,  all  the 
equipment  of  the  MB-339  CD  avionics  system  were 
individually  tested  for  acceptance  using  laboratory  test 
sets  based  on  PC’s  and  commercial  software  packages. 
This  approach  allowed  verifying  the  functionality  of 
the  units  autonomously,  before  performing  the  actual 
integration  tests  performed  at  the  avionics  Rig. 

The  adopted  avionics  Rig  was  capable  to  reproduce  the 
aircraft  interfaces,  to  provide  the  test  engineer  with 
representative  cockpit  and  man-machine  interface,  and 
to  simulate  real  dynamic  flight  conditions  using  a  3-D 
flight  simulator  software  package  running  on  a  PC. 

The  avionics  Rig  was  used  not  only  for  testing  and 
verification  purposes,  but  also  for  pre-flight  evaluation. 
Particularly,  test  pilots  and  engineers  could  evaluate  the 
various  functions  of  the  avionics  system  and  relevant 
man-machine  interfaces,  obtaining  progressive 
refinement  and  optimisation  of  the  various  solutions 
and  minimising  costs  by  reducing  the  number  of  flight 
test  sorties  required. 

The  avionics  Rig  modular  architecture  and  the 
extensive  use  of  commercial  hardware  and  software 
tools  allowed  easy  implementation  of  the  functions 
associated  to  the  integration  of  new  equipment. 

Flight  test  activity,  conducted  on  the  prototype  aircraft, 
was  carried  out  by  both  company  and  Air  Force  test 
pilots  to  demonstrate  the  expected  performances, 
functionalities  and  man-machine  interfaces  under  real 
flight  conditions.  The  prototype  aircraft  was  equipped 
with  state-of-the-art  flight  test  instrumentation  based  on 
COTS  acquisition  and  recording  systems  (e.g.. 
Differential  GPS,  Magnetic  Recorders  and  Telemetry 
Data  Link). 


3.6  Certification  and  Logistics  Support 

COTS  integration  demonstrated  important  benefits 
during  the  system  life  cycle  and  specific  advantages  in 
certification  and  product  support.  In  fact,  the 
certification  process  did  not  address  individual  COTS 
components,  modules  or  subassemblies,  as  it  was  aimed 
at  specific  equipment  functions.  However,  equipment 
certification  credit  was  gained  by  establishing  that  the 
various  components  were  selected  on  the  basis  of 
proven  technical  suitability  for  the  intended  application 
(e.g.,  component  temperature  range,  power  or  voltage 
rating,  quality  control  procedures  of  the  component 
manufacturer  and  COTS  availability/implementation  in 
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similar  applications).  Furthermore,  COTS  derived 
products  did  not  require  additional  custom  engineering 
and  support  effort,  because  the  commercial  equipment 
manufacturers  provided,  as  required,  continuous 
assistance  in  solving  obsolescence  of  electronic  devices 
and  circuits. 


4.  CONCLUSIONS 

In  this  paper  we  have  presented  a  living  application  of 
COTS  equipment  and  components  integration  in  a 
modem  avionics  architecture. 

Particularly,  we  have  attempted  to  emphasise  the 
impact  of  a  COTS  approach  on  the  various 


development  phases  of  the  MB-339CD  advanced 
trainer  aircraft. 

A  complete  description  of  the  new  avionics  has  been 
provided  and  the  criteria  used  in  COTS  integration 
have  been  described  through  several  real  examples 
covering  different  design  areas  of  interest:  system 
architecture,  equipment  selection  and  components 
usage. 

The  approach  applied  in  the  development  of  the  MB- 
339CD  avionics  has  yielded  a  state-of-the  art  and  cost 
effective  solution  where  the  use  of  non-developmental 
equipment  and  COTS  components  has  provided  cost 
and  schedule  benefits  reducing  development  risk  and 
improving  logistics  supportability. 
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Overview 

This  new  computer  architecture  can  use  anything  from 
COTS  (Commercial  Off-The-Shelf)  microcontrollers  to 
the  latest  high-end  processors.  It  is  a  distributed  fault- 
tolerant  architecture  that  is  dynamically  reconfigurable  in 
the  event  of  device  failures,  and  is  fully  programmable  in 
conventional  high  level  languages.  By  using  a  simple 
two-level  hierarchy  with  redundant  control  processors 
that  configure  the  I/O  (Input/Output)  processor 
arrangement,  even  the  failure  of  several  processors  will 
have  no  effect  on  data.  An  example  is  given  of  a  real¬ 
time  data  acquisition  system  with  a  total  cost  for  a  16 
channel  device  with  mixed  sync/async  and  proprietary 
baud  rates,  of  less  than  $500  in  parts.  This  example 
system  can  be  reconfigured  to  any  arrangement  of  16  or 
less  serial  interfaces. 

The  architecture  is  flexible  and  can  be  expanded  into  two 
levels:  status,  health  and  monitoring;  and  clustered  I/O 
and  processing.  Additional  expansion  to  a  third  level 
would  add  adaptive  learning  aspects.  Each  processor  can 
be  dynamically  removed  or  replaced,  and  is  designed  to 
run  a  minimal  amount  of  processor-specific  software  - 
about  1  -2  kilobytes  of  code,  which  allows  each  new  type 
of  processor  added  to  be  configured  to  respond  as  a 
generic  processor  /  CPU  (Central  Processing  Unit).  This 
facilitates  the  addition  of  new  processors  with  a  minimal 
amount  of  development.  Present  software  may  need  to  be 
modified  to  take  full  advantage  of  this  architecture, 
although  by  using  currently  available  distributed 
processor  operating  systems,  most  of  the  modifications 
can  be  avoided.  The  layout  of  the  architecture  allows 
both  obsolete  and  state-of-the-art  processors  to  work 
together,  and  transparent  replacement  of  obsolete 
processors  with  newer  ones.  Some  current  software 
design  methodologies  can  be  applied  to  configuring  the 
hardware  architecture,  such  as  CORBA  -  The 
architecture  lends  easily  to  Object  Request  Brokers  -  e.g. 
cluster  CPU  replacements  can  be  specified  by  using 
Interface  Definition  Language  -type  description  of  CPU 
functionality,  making  it  CORBA-like  from  a  hardware 
perspective.  Further  development  and  acceptance  of  this 
architecture  can  lead  to  significant  cost  savings  and 
mitigate  obsolescence  in  future  computer  design. 


Introduction 

In  general,  CPU  speeds  increase  faster  than  it  is  practical 
to  replace  them  following  Moore’s  law  -  speed  doubling 
every  18  months  or  so. 

Much  of  current  software  needs  the  increased  speed  for 
various  reasons,  which  include  poor  coding  practices  and 
inefficiency.  There  are  some  of  us,  of  course  who  yield 
to  the  marketing  pressures  to  have  the  fastest  processor 
commercially  available  for  their  own  satisfaction.  This  is 
something  like  buying  a  Ferrari  for  the  sole  purpose  of 
driving  in  funeral  processions. 

Due  to  the  high  cost  of  constantly  upgrading  CPUs  to  the 
most  current,  and  the  financial  loss  of  decommissioning 
older  processors  after  only  two  or  three  years  of  service, 
we  need  to  find  an  effective  means  of  mitigating  this 
built-in  obsolescence.  The  obvious  solution  would  be  re¬ 
use.  There  are  several  ways  that  we  could  do  this.  One 
would  be  to  completely  redesign  the  CPU’s  architecture, 
which  would  not  be  in  the  semiconductor  manufacturer’s 
best  interest  (but  neither  would  effective  re-use  plans  that 
reduced  their  future  sales  volume).  Another  way  would 
be  to  design  a  computer  architecture  to  allow  the 
incorporation  of  both  obsolete  and  current  processors 
working  together  and  allow  future  processors  to  just 
‘plug-in’  to  this  architecture.  We  will  define  our  goals 
for  this  architecture  and  details  of  implementation  in  the 
rest  of  this  paper. 

Goals: 

1)  A  low-cost,  upwardly  scalable  architecture  that  is  built 
from  current  COTS  processors.  The  scalability  will  allow 
future  processors  to  work  along  with  obsolete  ones  in  a 
synergistic  way. 

2)  Full  fault-tolerance,  where  a  processor(s)  can  be 
physically  unplugged  without  losing  data  or  overall 
functionality. 

We  want  to  do  this  with  the  most  cost-saving  approach. 
That  would  mean  using  obsolete  processors  in  current 
equipment  with  state-of-the-art  processors  added  to  the 
architecture  without  large  changes  in  software  or 
hardware. 

The  objectives  are  to  produce  a  seamless  scalability 
between  the  old  processor  and  new  processors,  as  well  as 
eliminating  single  point  failures  with  the  inherent 
redundancy  of  this  architecture.  Thus,  expensive  state-of- 
the-art  updates,  which  rapidly  become  obsolete,  can  be 
replaced  with  a  distributed  architecture  that  supports  both 
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current,  past  and  future  processors  working  together  in  a 
synergistic  manner. 

The  software  embedded  in  each  processor  is  easily 
maintained  code  which  effectively  translates  each  unique 
type  of  processor  into  a  generic  one  in  order  to  integrate 
it  into  this  distributed  architecture.  That  also  allows  each 
CPU  to  work  with  small  but  powerful  real-time  operating 
systems,  as  well  as  treat  the  processors  as  functional 
objects  to  be  added  or  deleted  from  the  distributed 
architecture. 

Current  Computing  Systems: 

In  pre-COTS  days,  the  CPU  was  designed  for  specific 
tasks.  An  example  from  about  1943  is  Colossus,  which 
was  an  electromechanical  processor  designed  for  code- 
breaking,  and  had  its  programming  hardwired  or  set  by 
patch  panel  jumpers.  Later  on,  software  written  for 
processors  allowed  them  to  do  general  tasks  and 
eventually  multi-task.  More  recently,  processors  were 
designed  for  particular  classes  of  problems,  such  as  DSPs 
for  signal  processing,  32  /  64  bit  CPUs  for  desktop  PCs, 
and  embedded  controllers  for  small  and  medium  scale 
device  control. 

We  currently  have  a  variety  of  COTS  and  proprietary 
systems  that  are  either  networked  or  stand-alone 
throughout  the  world.  Typically,  COTS  life  is  2-3  years. 
Large  systems  or  mission  computers,  which  may  be 
based  on  COTS  components,  are  usually  obsolete  by  the 
time  that  they  are  fully  deployed.  This  is  due  to  a  long 
(by  computer  state-of-the-art  standards)  initial  life  cycle 
development  and  deployment.  Advanced  proprietary  or 
prototype  systems  usually  have  a  longer  life,  but  at  a 
much  greater  cost. 

High-end  systems  with  multiple  processors  and  /  or 
special  parallel  processing  schemes  use  specialized 
parallel  algorithms  that  tend  to  lock  in  software  to  the 
specific  architecture. 

An  example  laboratory  system  is  shown  which  replaced 
a  proprietary  architecture  that  had  reached  the  end  of  its 
useful  or  maintainable  life.  A  novel  approach  was  taken 
to  create  a  small  scalable  architecture  based  on  COTS 
that  maintained  full  functionality  and  most  software 
compatibility  with  upward  expandability. 

Example  System 

This  example  system  was  originally  a  large  rack¬ 
mounted  VME-based  system  with  proprietary  boards. 
Additionally,  the  base  system  was  obsolete  and  the 
proprietary  boards  had  little  or  no  supporting 
documentation.  The  objective  here  was  to  upgrade  this 
system  to  a  current  scalable  system  for  a  hardware  cost 
of  less  than  $1000.  The  system  should  run  a 
commercially  or  freely  available  operating  system,  and 
the  upgrade  should  have  minimal  or  no  impact  on 
functionality. 

The  new  system  should  also  be  readily  portable,  so  it  can 
be  designed  into  a  briefcase  with  a  laptop  running  Linux 


as  a  display  unit,  and  a  master  controller  board  of  about 
30x30  CMS  in  size. 

This  master  board  would  include  the  16  data  channels 
that  the  original  equipment  monitored  and  use  four 
microcontrollers  ("Basic  Stamp"  microcontrollers)  to 
each  acquire  four  channels  of  serial  data  at  the 
proprietary  baud  rates,  sync  or  async  depending  on 
channel.  This  board  has  the  capability  to  add  channels  by 
just  adding  another  microcontroller  for  each  four 
channels. 

(See  Fig.  0) 


Since  each  PIC  microcontroller  chip  is  less  than  4cm^, 
the  entire  board  and  connectors  is  small  and  fits  in  the 
briefcase  with  the  laptop  computer.  Additionally,  each 
PIC  microcontroller  has  several  unused  I/O  channels  that 
can  be  used  as  spares. 

In  summary: 

(1)  The  large  rackmount  system  was  reduced  in  size  to  a 
briefcase. 

(2)  A  rigid,  non-expandable  system  was  made  upwardly 
scalable. 

(3)  The  entire  system  is  COTS  based. 

(4)  The  system  costs  less  than  $1000  in  hardware 
(depending  on  the  cost  of  the  laptop  -which  could  be  an 
older  model  for  $300-$500). 


Improving  the  Original  Concept: 

Lets  re-frame  the  example’s  approach  by  using  cheap 
CPUs  in  clusters  to  handle  larger  problems.  Is  this  like 
the  DIS  (Distributed  Interactive  Simulation),  currently 
renamed  HLA  (High  Level  Architecture),  where 
networked  systems  participate  in  simulations  from  any 
location,  and  any  system  may  deploy  a  real-time  object 
into  the  simulation  world  such  as  an  adversary  or  threat 
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platform?  Not  really,  as  that  is  meant  to  support  the 
HLA’s  interface  aspects  for  simulations. 

We  would  want  something  that  could  handle  generic 
distributed  processing  as  well  as  specific  aspects  of 
computational  processing,  and  perhaps  parallel 
interfacing  for  multiple  data  channels.  This  architecture 
would  be  similar  in  function  to  the  SETI@home  web 
site,  where  you  are  offered  a  chance  to  participate  in 
SETI's  search  and  data  processing  as  well  as  a  nice 
screen  saver.  This  is  in  exchange  for  allowing  your 
computer  to  be  used  during  idle  time  as  one  node  in  their 
distributed  processing  architecture  to  process  their  data. 
The  SETI  architecture  is  primarily  a  SIMD  (Single 
Instruction  Multiple  Data)  type  of  parallel  machine, 
where  a  primary  control  machine  is  needed  over  all  the 
node  machines,  and  this  could  be  a  source  for  single¬ 
point  failure.  A  comparison  could  also  be  made  with  our 
design  to  the  Beowulf  architecture,  in  that  it  can  run  on 
existing  hardware,  and  can  use  open  source  software  for 
the  most  part.  There  are  differences,  however  in  that  the 
Beowulf  cluster  architecture  is  designed  to  run  on  private 
high  speed  LANs,  and  not  over  a  distributed  network. 
According  to  the  founder  of  the  Beowulf  architecture,  it 
will  not  be  designed  to  run  over  the  Internet,  or  a  similar 
distributed  approach.  Again,  Beowulf  clustering  is 
designed  to  have  a  master  node  control  the  cluster. 

Lets  consider  the  best  ways  to  build  an  architecture  from 
varied  and  possibly  obsolete  components.  We  would 
probably  want  a  MIMD  (Multiple  Instruction  Multiple 
Data)  type  architecture,  or  a  SIMD  /  MIMD  mix  of 
clusters  that  can  be  dynamically  reconfigured.  In  other 
words,  each  cluster  could  be  SIMD  for  fault  recovery, 
and  the  set  of  clusters  would  enable  a  MIMD 
architecture.  We  would  also  want  to  fall  back  to  minimal 
configurations  if  we  should  lose  many  of  the  clusters. 
We  will  examine  that  first: 

Start  out  with  a  small  architecture,  and  call  it  level  0. 
This  architecture  may  consist  of  only  a  few  CPUs  that 
have  simple  rules  embedded  into  about  1-2  kilobytes  of 
code  for  each  processor.  The  code  would  also  allow  each 
processor  to  appear  generic  to  the  others,  such  that  each 
one  could  use  a  common  generic  instruction  set.  There 
would  be  no  need  for  a  true  operating  system  on  each 
processor.  These  processors  could  be  microcontrollers, 
DSPs  or  other  embedded  systems  as  well  as  high  level 
CPUs.  A  single  operating  system  would  then  run  over 
all  the  processors. 

A  larger  version,  which  we  will  call  level  1,  can  use 
small  kernel  real-time  operating  systems  for  each 
processor,  or  just  each  cluster  of  processors. 

The  code  embedded  in  each  processor  would  be  similar 
to  the  level  0  approach,  and  may  have  minor  differences 
for  classes  of  functionality,  such  as  I/O  clusters  vs. 
status,  health  and  management  clusters.  These  classes 
could  define  clusters  as  particular  types  of  objects  with 
strong  object  models  defined  in  tools  such  as  UML, 
Rhapsody  or  Rational  Rose  for  object  modeling,  as  well 
as  CORBA  extensions. 

The  operating  system  running  on  each  processor  or 
cluster  would  have  a  small  footprint  (400k  or  so)  such  as 


in  RTMX,  PROSE  and  others,  and  be  POSIX  1003.1b 
real-time  extension  compliant. 


Fault  Adaptation: 

If  one  or  more  processors  are  unplugged  or  damaged, 
how  can  we  handle  this?  What  if  a  particular  processor 
has  an  inherent  exploitable  vulnerability  such  that  an 
attack  from  afar  can  succeed? 


Fault  Adaptation 


♦  WckedV\felcb 
maliciously  unplugs 
a  processor -now 

:??? 

♦  V\ifeilcb  attacks  from 


Figure  2  -  How  do  we  deal  with  Faults? 


Both  these  situations  call  for  some  type  of  fault 
tolerance,  usually  not  found  in  generic  or  COTS 
machines.  We  can,  however  determine  an  architecture 
that  incorporates  this  scope  of  fault  avoidance. 

By  using  a  clustered  approach  to  disparate  CPUs  we  can 
avoid  these  shortcomings  inherent  in  conventional 
systems. 

The  design  described  here  is  optimal  for  multi-channel 
I/O  intensive  operations,  but  is  not  limited  to  that,  and 
has  far  more  diverse  uses.  An  example  of  this  would  be 
low  bandwidth  but  high  levels  of  numerical  calculations 
that  work  well  in  a  distributed  processing  environment. 
We  define  three  levels  of  complexity  in  the  architecture 
(more  can  be  defined  later).  Each  level  has  processors 
organized  into  clusters  of  two  or  three  for  fault 
avoidance.  These  clusters  can  act  as  a  single  processor  if 
complete  data  recovery  is  mandated,  and  as  such  inter¬ 
processor  communication  shares  data  and  processing  so 
that  any  single  processor  failure  will  not  affect  data  or 
processing  capability.  In  some  ways  this  is  similar  to  the 
RAID  aspect  of  redundant  disks  for  critical  data  storage 
and  recovery. 
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Example  Level  0  architecture: 

This  consists  of  small  clusters  of  redundant-functionality 
microcontrollers  or  standard  CPUs  that  are  not 
necessarily  identical,  each  of  which  has  several  I/O 
channels,  with  a  digital  switch  layer  to  isolate  any  major 
electrical  faults.  This  way  if  the  external  devices  that  are 
being  interfaced  to  have  noisy  data  or  unstable  voltage 
fluctuations,  the  processors  are  not  damaged.  Since  the 
monitor  code  executing  on  each  microcontroller  is 
almost  identical  (identical  if  same  type  /  model  of 
controller)  and  consists  of  a  few  kilobytes  to  make  these 
generic  in  nature,  any  damage  to,  or  physical  removal  of 
any  processor  does  not  affect  the  data  or  processing  in 
any  way.  This  code  also  monitors  neighbor  status  and 
handles  basic  I/O  functions. 

We  have  a  small  and  efficient  real-time  system,  on  which 
we  can  optionally  load  a  distributed  operating  system. 
The  operating  system  would  treat  each  cluster  as  a  single 
processor,  with  the  embedded  monitor  code  "translating" 
instructions  to  run  as  a  generic  processor. 


Level  0  -  Example  AnchitECbure 
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Figure  3  -  a  level  0  example 


while  managing  to  save  the  data  in  temporary  storage. 
By  handling  faults  in  this  way,  a  race  condition  could  be 
avoided  which  would  occur  if  part  of  the  data  were  in  a 
non-local  CPU  when  the  one  in  the  local  cluster  failed. 
Rule  2:  Association  -  direct  data  to  associated 
destinations  (process  or  memory  block  in  common).  This 
method  of  “chunking”  data  also  mitigates  similar  race 
conditions,  or  skewed  timing  problems  that  were 
mentioned  in  rule  1 . 

Rule  3:  Selection  -  "hot"  or  pre-selected  runner-up 
processor  affiliated  with  active  processor  in  each  cluster. 
This  allows  a  pre-selected  replacement  for  failed  CPUs 
in  a  lossless  manner.  In  situations  where  there  are  an  odd 
number  of  processors  after  a  fault,  the  lone  CPU  would 
affiliate  with  either  the  node  of  two  CPUs  under  the 
heaviest  load  or  a  node  of  two  CPUs  in  the  closest 
proximity. 

Rule  4:  Health  -  IPC  (inter-processor  communication)  or 
at  least  “ping”  between  affiliated  processor  and  runner- 
up.  This  keeps  a  close  watch  on  when  a  CPU  needs 
replacement  due  to  failure  or  when  a  lone  CPU  can  join  a 
cluster  by  following  the  selection  rule  above. 

Rule  5:  Failure  mode  -  hunt  for  available  processor  if 
runner-up  fails,  and  check  for  I/O  saturation.  Call  for 
"help"  from  another  cluster  if  saturated.  This  is  the  mode 
that  a  clustered  CPU  enters  when  it  loses  its  associate 
CPU  in  the  cluster. 

We  could  apply  all  of  this  to  the  example  architecture  in 
Figure  1,  without  any  significant  increase  in  cost  for 
hardware. 

Level  1: 

Inclusive  of  level  0,  but  level  1  has  functionality  divided 
over  two  or  more  layers  of  clusters  -  first  layer  is 
clustered  I/O  or  CLIO.  Next  layer(s)  is  status  health  and 
management  (SHAM).  The  original  ruleset  as  well  as 
new  rulesets  apply,  defining  more  specific  boundaries  on 
SHAM  and  CLIO  layers.  Enhanced  aspects  are  also 
applied,  such  as  intelligent  /  adaptive  configuration 
interfaces,  to  be  used  by  level  2  architectures. 

The  functionality  still  remains  overlapping  with  the  level 
0  architecture,  so  that  if  an  entire  layer  is  lost  due  to 
failure,  the  architecture  will  fall  back  to  level  0  hopefully 
without  any  significant  loss  of  data  while  maintaining 
full  functionality. 


Level  0  Rules: 

Details  on  the  level  0  rules  explain  how  we  can 
accomplish  our  objectives  for  fault  management,  health 
monitoring,  and  generic  processor  functionality  in  a 
small  (<  2  Kbytes)  code  space.  For  very  different 
processor  architectures  some  parts  of  this  code  would 
need  to  be  modified  to  accommodate  unique  aspects.  We 
define  five  rules  that  apply  to  the  level  0  architecture, 
and  also  to  varying  degree  to  the  higher  levels  as  well: 
Rule  1:  Relation  (intrinsic)  -  keep  related  I/O  in  localized 
cluster(s).  On  a  small  scale  this  would  mean  that  I/O 
from  a  common  or  related  source  would  be  handled  by 
one  cluster,  so  that  if  a  CPU  failed,  then  its  alternate(s) 
would  take  over  for  it  and  request  another  backup  CPU 
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Example  Level  1  Architecture: 

As  seen  in  the  diagram,  the  same  clustering  is  used  in  the 
level  1  design,  but  the  clusters  that  handle  I/O  are  in  a 
separate  layer  from  the  status,  health  and  management. 
The  two  layers  communicate  with  each  other  similar  to 
the  single  layer  level  0  via  inter-layer  channels,  and  yet 
maintain  the  intra-layer  and  intra-processor 
communications  as  well.  Inter-layer  communications  are 
kept  short  for  the  most  part,  unless  a  major 
reorganization  of  layers  needs  to  take  place.  This 
minimizes  overhead  on  interprocessor  communication 
links. 

Digital  communication  in  and  between  layers  could  be 
accomplished  by  an  internally  incorporated  USB 
interface  for  809xx  series  microcontroller,  or  could  be  an 
Ethernet  interface  built  into  a  microcontroller  (I  think 
somebody  already  has  one  out  there...).  That  way  each 
cluster  could  pick  up  a  portion  of  the  network  load 
processing. 

Keep  in  mind  that  these  processors  do  not  need  to  be 
state-of-the-art,  but  obsolete  and  inexpensive  ones  could 
suffice.  Typical  standard  microcontrollers  cost  about  $1- 
$2.  Older  PC  CPUs  cost  $10-$30,  and  can  have  up  to 
50%  of  the  maximum  processing  power  available  today. 

Fault  adaptation  on  intelligent  multi-kernel  clusters 
(Level  2): 

This  advanced  version  of  the  architecture  can  actively 
reconfigure  itself  for  fault  avoidance,  and  adapts  to 
hostile  attacks.  An  example  would  be  an  attack  from  a 
networked  intelligent  agent  that  focuses  onto  perceived 
weakness  in  the  architecture,  or  even  operating  systems 
executing  on  it.  The  system  would  be  able  to  compensate 
for  and  possibly  repel  future  attacks.  This  is  feasible 
because  of  the  nature  of  a  distributed  system  like  this.  If 
one  or  more  layers  handle  adaptive  learning,  then  it  can 
behave  like  a  neural  network  or  other  adaptive  systems. 


The  degree  of  complexity  in  the  level  0  or  level  1 
architectures  may  not  be  sufficient  to  accomplish  this. 
However,  in  this  level  2,  there  are  at  least  three  layers, 
the  first  two  handling  the  aspects  of  level  1,  and 
additional  layers  the  adaptive  aspects. 

Enhancing  aspects  of  the  level  2  paradigm  can  allow 
separate  kernels  to  run  on  each  node,  with  socket-based 
communication  handling  I/O  and  IPC. 

Several  real-time  operating  systems  can  exploit  the 
benefits  of  this  architecture.  Two  examples  of  operating 
systems  that  have  excellent  security  built  in  are; 

1)  RTMX  -  this  could  run  as  1  kernel  per  node.  It 
exhibits  the  full  Berkeley  support  for  export,  NES  and 
shared  memory,  and  incorporates  high  level  encryption. 
This  has  recently  been  donated  to  the  OpenBSD  project, 
as  it  is  open  source  code.  This  means  that  in  future 
releases  of  OpenBSD,  the  real-time  portions  of  RTMX 
will  be  incorporated.  If  these  future  versions  support  a 
small  kernel  as  in  RTMX,  then  OpenBSD  can  also  be  a 
viable  operating  system  for  this  architecture. 

2)  PROSE  -  Developed  at  Sandia  Labs,  this  could 
function  as  1  kernel  per  cluster  or  even  layer,  as  the 
operating  system  supports  a  real-time  kernel  running 
over  a  multi-node  network.  This  was  to  be  certified  by 
NS  A  to  the  B  3  level. 

Both  of  these  can  be  placed  into  ROM  for  each  processor 
or  globally  shared,  as  the  entire  kernel  is  less  than  400 
Kbytes  in  size.  They  are  also  both  publicly  available. 


Relationship  of  Levels  0, 1,  and  2: 


Figure  5  -  Relationship  between  Levels 


The  relationship  between  the  three  levels  just  described 
is  as  subset  /  superset,  where  level  0  is  a  subset  of  level  1 
and  level  2,  level  1  is  for  the  most  part  a  subset  of  level  2 
with  some  minor  exceptions  that  have  to  do  with 
adaptive  vs.  non-adaptive  fault  management.  The 
purpose  of  designing  the  architecture  in  this  way  is  to 
allow  full  scalability  between  having  a  few  CPUs  form  a 
level  0  to  adding  on  more  CPUs  to  the  architecture  over 
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time  to  eventually  achieve  level  2.  Beyond  level  2  can 
still  be  treated  as  a  level  2  configuration,  with  enhanced 
functional  features  typical  of  a  massively  parallel 
distributed  processor  machine. 

Perspectives  and  methodologies: 

This  distributed  architecture  is  similar  to  a  neural 
network  in  many  ways,  not  least  of  which  is  its  ability  to 
adapt  and  self-organize  in  larger  versions.  An  interesting 
aspect  that  would  allow  us  far  more  control  over  the 
internal  organizational  interconnectivity  would  be  to  use 
tools  from  the  software  engineering  world  and  take  an 
object  oriented  approach.  Currently,  the  object-oriented 
approach  is  applied  only  to  software.  For  optimal 
benefits  to  be  derived  from  object-oriented  design,  the 
methodology  should  be  applied  system- wide,  i.e.  to 
hardware  module  objects  as  well  as  software.  We  could 
then  bring  the  hardware  and  software  worlds  together 
into  an  object  based  system  paradigm. 

The  architecture  described  in  this  paper  lends  itself  to 
this  type  of  approach.  If  we  treat  these  architectures  as 
object  models  then  we  can  use  existing  tools  such  as 
Rhapsody,  which  is  designed  to  work  in  embedded 
systems  and  is  a  UML  (Unified  Modeling  Language) 
visualizing  environment  with  a  built-in  model  checker. 
This  can  develop  the  common  ruleset  generation  for  each 
level,  and  possibly  map  layer  connectivity. 

Hardware  layouts  can  be  managed  by  a  CORBA-like 
environment,  with  clustered  CPU  mappings  defined  by 
an  IDL  (interface  definition  language)  and  managed  by 
an  ORB  (object  request  broker).  The  objective  here  is  to 
accomplish  a  system- wide  object-oriented  design  not  just 
limited  to  software.  Ultimately  this  may  create  a  more 
consistent  mapping  of  software  processes  onto  hardware 
resources. 

Finally,  and  for  future  research,  a  large-scale  version  of 
this  may  prove  useful  as  an  inexpensive  alternative  to  the 
quantum  computing  environment  of  Shor  &  Lloyd  (Bell 
Labs  /  MIT),  at  least  until  that  becomes  economically 
competitive. 


govern  fault  related  mitigation,  we  can  construct  a  highly 
modular  paradigm  for  distributed  processing. 

The  modular  design  fits  well  with  the  concepts  of  OOD 
and  use  of  UML  for  definition,  and  CORB  A  aspects  such 
as  ORB  for  hardware  modules. 

Further  development  of  this  architecture  can  result  in 
defining  a  new  standard  to  apply  to  distributed 
architectures.  This  standard  would  simplify  hardware 
redesign  through  the  modularity  of  an  object-oriented 
hardware  paradigm  with  tremendous  cost  saving  benefits 
by  re-use  of  existing  low  cost  obsolescent  processors. 
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Conclusion: 

This  distributed  architecture  is  based  on  COTS  systems 
and  essentially  does  a  re-use  of  obsolescent  CPUs.  The 
distributed  architecture  constructed  can  be  done  at 
minimal  cost  compared  to  state-of-the-art,  or  proprietary 
systems.  It  produces  a  robust  architecture  that  is 
upwardly  scalable,  fault  tolerant  and  dynamically 
reconfigurable  so  that  mission  critical  data  is  preserved. 
The  system  constructed  from  this  architecture  can  run 
real-time  and  is  a  distributed  parallel  computer. 
Essentially,  it  is  a  supercomputer  built  from  obsolete  and 
current  components.  The  trade-off  of  reliability  for 
extreme  speed  is  done  with  distributed  modularly  defined 
clustering.  By  organizing  the  methodology  of 
implementing  this  architecture  into  three  levels  that  are 
based  on  the  degree  of  functionality  and  complexity,  and 
basing  the  core  level  on  a  set  of  intrinsic  rules  that 
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Summary 

After  providing  an  introduction  to  the  obsolescence 
problem,  this  paper  explains  how  the  topic  is  handled  to 
dated,  using  an  airborne  radar  system  development  as  an 
example.  In  this,  the  supplier  primarily  reacts  on 
obsolete  components  with  post  design  measures.  In 
contrast  to  this  a  pro-active  approach  is  suggested  that 
starts  with  defining  an  architecture  that  eases  the 
substitution  of  obsolete  components  and  allows  upgrades 
without  involving  major  redesigns.  This  includes  the 
need  to  safeguard  the  effort  spend  for  developing  and 
qualifying  application  software. 

The  article  presents  a  modular  structured  signal 
processing  architecture  that  employs  COTS  modules  and 
standards.  It  discusses  the  ability  of  such  an  architecture 
to  cope  with  the  obsolescence  problem  by  separating 
interfaces  from  processing  units  and  applying  COTS 
interface  standards.  Means  of  the  designer  are  examined 
that  allow  to  proactively  design  a  processor  that  is  likely 
to  survive  hardware  and  software  component  changes  at 
minimum  cost.  Forming  standard  building  blocks  that 
encapsulate  processing  functions  is  presented  as  an 
approach  that  will  considerably  reduce  the  involved  risk. 

Situation  Today 

The  Obsolescence  Problem 

Development  and  supply  of  todays  digital  components 
has  been  adapted  to  the  needs  of  the  commercial 
markets,  especially  to  support  mobile  communication 
and  consumer  products,  as  these  by  far  outnumber  the 
required  components  in  the  defence  industry.  This 
affects  both,  the  components  availability  and  their 
capabilities. 

The  life  cycle  of  telecommunication  and  consumer 
products,  e.g.  mobile  telephones,  ranges  between  2  to  5 
years,  whereas  the  defence  products  show  a  life  cycle 
time  in  the  order  of  20  years  and  more.  Suppliers  for  key 
components  like  memory  and  microprocessors  have  life 
cycle  times  of  about  2  to  4  years,  adopted  to  their  main 
customers.  As  a  result,  a  defence  product  has  to  cope 


with  the  same  component  becoming  obsolete  in  the  order 
of  about  5  to  10  times  during  the  equipment  life  time. 
This  will  most  likely  start  at  the  beginning  of  the  product 
life  cycle,  i.e.  during  the  definition  and  development 
phases. 


Product 


Component 

Generation 


Figure  1;  Equipment  and  Component  Life  Cycle 

The  virtue  of  such  frequent  component  upgrades  is  a 
permanent  enhancement  in  performance  and 
functionality  of  components  that  includes  low  power 
consumption  as  the  supply  voltage  levels  drop.  In  the 
past,  military  applications  drove  the  performance  and 
functional  specification  of  digital  components.  This  has 
changed,  as  the  telecommunication  and  consumer 
markets  produce  nowadays  complex  products  as  well, 
with  a  need  for  high  performance,  low  cost  components. 
The  major  differences  are  the  harsh  environmental 
conditions  a  component  has  to  sustain  in  a  defence 
product  as  well  as  the  product  reliability  it  has  to 
support. 

For  airborne  applications  in  an  military  fighter  aircraft, 
the  most  severe  environmental  conditions  include: 

Wide  temperature  range  of  both  the  ambient  and  the 
cooling  air  (if  any). 

Humidity,  especially  when  high  temperature  and 
pressure  gradients  are  to  be  faced. 

Mechanical  shock  and  vibrations 
MIL  standard  components  have  been  able  to  cope  with 
these  conditions,  as  they  were  designed  for  them. 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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However,  due  to  the  rapidly  diminishing  share  of 
military  applications  on  the  semiconductor  market,  MIL 
standard  components  are  vanishing. 

Industrial,  and  especially  commercial  grade  components 
specifications  do  however  not  consider  these 
environmental  conditions.  As  they  are  designed  for 
cheap  mass  production,  their  design  includes: 

Plastic  encapsulated  modules  (PEM) 

Low  voltage  supply 

Since  the  life  cycle  of  commercial  products  is  much 
shorter  compared  to  military  avionics  equipment,  the 
required  product  reliability  can  be  lower.  In  military 
applications  a  primary  failure  rate  of  only  a  few 
occasions  per  1000  operating  hours  can  be  accepted. 
Equipment  that  is  involved  in  flight  safety  has  to  fulfil 
even  more  stringent  reliability  requirements. 

Whether  the  predicted  reliability  of  equipment  applying 
industrial  /  commercial  components  suffices  depends 
very  much  on  the  prediction  method.  MIL  Handbook 
217  is  generally  considered  to  be  too  pessimistic 
compared  to  other  methods. 

PEMs  may  not  only  reduce  the  equipment  reliability  in 
severe  environmental  conditions,  but  also  require  careful 
storage  to  avoid  penetrating  humidity  and  pin  corrosion. 
The  same  level  of  care  should  be  taken  during 
production  to  avoid  e.g.  contact  with  perspiration. 

Eigure  2  summarises  the  facets  of  the  obsolescence 
problem  as  outlined  above.  Component  suitability  may 
be  tackled  by  design  methods,  of  which  some  are 
outlined  later  in  this  paper.  Regardless  of  those,  the 
problem  of  component  availability  and  high  frequency  of 
upgrades  remains  and  will  most  likely  cause  a  number  of 
serious  impacts  on  any  military  development  project: 
Production  of  military  products  will  be  more 
difficult  as  the  list  of  components  will  change 
frequently  during  series  production. 

It  becomes  increasingly  difficult  to  procure  spare 
components. 

Permanent  and  frequent  design  activities  are 
necessary  during  series  production.  Obsolete 
components  will  have  to  be  faced  already  during  the 
definition  and  development  phases. 

An  ever  increasing  gap  between  the  technology  used 
in  commercial  products  and  the  technology  applied 
in  military  applications. 

The  inevitable  re-designs  of  processing  HAV  require 
the  transfer  of  the  highly  expensive  application  SAV 
on  new  processing  platforms. 

The  error  in  programme  cost  estimates  will  increase 
as  the  effort  for  future  obsolescence  removal 
activities  is  difficult  to  estimate,  but  a  significant 
factor. 

All  of  the  above  will  increase  the  product  cost  over  the 
product  life  time.  However,  with  methods,  which  are 
described  in  the  following  sections,  these  costs  could  be 
minimised  (except  for  the  last  bullet  above,  which  will 
not  be  covered  in  this  paper). 


Figure  2;  Obsolescence  Problem  Tree 


Today’s  Strategy 

Avionics  systems  coming  today  to  series  production  are 
based  on  developments  in  the  90ties.  In  the  digital  and 
especially  in  the  processing  area  they  were  driven  by 
thoughts  as 

Minimise  the  number  of  different  components  and 
therefore  maximise  the  amount  of  equal  components 
for  series  production 

Use  of  “Common  Standard  Boards” 

Increase  production  quantity  of  equal  boards 
with  equal  processes 

If  required,  support  the  processing  power  by 
dedicated  ASIC’s,  e.  g.  as  hardware  accelerators  for 
mathematical  operations 

The  cycles  from  development  to  production  was  planned 
as  phased  approach  with 
Development  Phase 

Qualification  Phase  (which  may  be  part  of  the 
former  phase) 

Production  Investment  Phase  to  prepare  the 
necessary  facilities  and  tooling  for  series  production 
Series  Phase 


Development 


Qualification 


Production 

Investment 

1  Series 
1  Production 

Figure  3:  Equipment  Phases  vs.  Time 

Keeping  in  mind  the  development  duration  for  military 
avionics  products  of  approximately  8  to  10  years  and  the 
progress  made  in  technology  between,  the  supplier  is 
faced  with  the  challenge  that  the  just  developed  and 
qualified  product  is  not  manufacturable.  This  is 
extremely  valid  in  the  processor  and  ASIC  area  were,  for 
example,  the  physical  structures  had  shrinked  from  1.5 
pm  down  to  0.35  pm  and  below  in  the  meantime. 
Therefore,  most  of  the  ASICs  became  obsolete. 

It  had  become  necessary  to  expand  the  Production 
Investment  Phase  by  an  additional  development  phase  to 
mitigate  known  obsolescence  at  time  of  starting  the 
Production  Investment  activities.  This  results  also  in  an 
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additional  (and  at  least  partly)  re-  qualification  of  the 
modified  equipment. 

Unfortunately,  the  injection  of  a  re-  design  cycle 
mitigates  the  obsolescence  problem  only  at  the  moment, 
but  not  in  medium  and  long  term  aspects.  With  the 
ongoing  strong  decrease  in  the  availability  of  military 
components  forced  by 

disappearing  of  key  vendors  from  the  military 
market  (e.g.  LSI  Logic), 

company  sell  offs  in  the  ASIC  business  (e.g.  GEC 
Plessey,  TEMIC), 

change  in  base  technologies  (e.g.  ECL  supersedes 
CMOS,  3.x  V  replaces  5.0  V), 
the  obsolescence  problem  overhauled  the  re-  design  and 
is  back  again.  This  situation  is  known  in  the  mass  market 
but  indeed  new  for  military  developments. 

Therefore,  to  come  to  a  production  phase  the  following 
options  are  possible  and  request  a  careful  component  by 
component  observation 
Re-Design 

If  a  certain  amount  of  components  is  obsolete  or 
marked  to  become  obsolete  in  shorter  time,  a  re¬ 
design  is  necessary  to  mitigate  the  obsolescence  risk 
for  the  start  phase  of  Series  Production. 
Re-Specification 

Components  specified  according  to  a  very  high 
quality  level  should  be  observed  if  a  lower 
qualification  level  could  be  accepted  and  if  the 
component  is  available  at  this  level  (e.g.  QPL 
component  replaced  by  MIL  883  type). 

LastTimeBuy 

Considering  the  time  consumed  for  a  re-  design  /  re¬ 
spin  of  complex  key  components  (e.  g.  ASICs)  it 
should  be  necessary  to  perform  a  Last  Time  Buy. 
This  possibility  should  also  be  selected  if  a 
component  becomes  obsolete  after  start  of  re-  design 
and  could  not  be  included  in  this  cycle. 

Any  of  the  above  discussed  possibilities  must  be  chosen 
after  careful  observation  regarding 
Schedule 
Risk 

Impending  re-  qualification 

Experience  in  an  avionics  project  shows  that  after 
finalisation  of  the  development  phase 

75  %  of  the  components  are  still  active 
1 1  %  of  the  components  require  a  re-  specification 
1  %  of  the  components  require  a  re-  design 
1 3  %  of  the  components  require  Last  Time  Buy 
The  Last  Time  Buy  number  in  this  example  is  quite  high 
as  the  design  key  elements  are  ASIC’s  which  become 
obsolete  by  reasons  discussed  above. 

In  any  case,  a  sophisticated  obsolescence  management 
has  to  be  established  to  observe  the  relevant  component 
market  and  gain  early  recognition  of  upcoming 
component  obsolescence.  As  efficient  as  the  established 
obsolescence  process  in  each  company  or  in  consortia  is, 
it  mainly  suffers  from 

Availability  of  Last  Time  Buy  Warnings 


Not  all  component  vendors  issue  early  warnings  for 
upcoming  obsolescence.  Today’s  practice  shows 
that  components  are  becoming  obsolete  without 
public  notice.  The  problem  is  recognised  by  the  user 
at  time  of  placing  an  additional  /  new  order. 

Number  of  avionics  systems  to  be  built  is  not  fixed. 
Forced  by  the  existing  lack  of  funding  at  the  military 
purchasers  the  total  number  of  items  to  be  built  is 
not  fixed  at  production  start.  This  means  that  the 
suppliers  keep  the  risk  in  definition  of  the  number  of 
systems  to  be  built  as  well  as  for  the  required 
logistic  spares  (item  and  component  spares) 

Financial  penalties 

Last  time  buy  of  components  bind  a  not  small 
amount  of  money  in  a  very  early  phase  of  Series 
Production  with  all  resulting  penalties  for  the 
financial  backer.  Note  that  not  seldom  the 
equipment  manufacturer  has  to  take  the  burden  to 
finance  this  stock. 

Technical  penalties 

Long  time  storage  of  components  may  influence  the 
processability  in  terms  of  e.  g.  solderability.  Whilst 
in  the  early  90ties  only  logistic  stock  components 
had  to  be  prepared  for  long  term  storage  and  stored 
in  special  stocks  (protective  gas  environment) 
nowadays  production  and  spare  components  have  to 
be  protected.  This  additional  effort  enhances  also  the 
overall  costs. 

Applying  above  principles  to  an  existing  avionics  project 
which  was  developed  in  the  90ties  and  comes  today  to 
first  Series  Production  deliveries,  the  financial  effort 
could  be  characterised  by 

Development  Phase  100  % 

Obsolescence  driven  re-  designs:  7  %  of  the  Devel¬ 
opment  Phase  during  Production  Investment  Phase 
Last  Time  Buys 

a)  Not  re-  designed  key  components:  5  %  of  the 
Development  Phase 

b)  Upcoming  obsolescence  after  Re-  designs:  1  % 
of  the  Development  Phase 

The  experience  from  the  example  project  could  be 
summarized  by 

Obsolescence  Management  and  mitigation  must 
start  with  the  Development  Phase 
Last  Time  Buy  of  (at  least)  components  is  opportune 
A  re-  design  cycle  between  Development  /  Quali¬ 
fication  and  Series  Production  forced  by 
obsolescence  is  necessary 

Revised  Approach 

All  of  the  current  methods  to  tackle  the  obsolescence 
problem  as  outline  above,  start  once  the  equipment 
design  is  finished  and  components  become  unavailable. 
During  the  80’ s  and  early  90’ s  the  electronic  component 
selection  process  in  military  airborne  applications  was 
mainly  driven  by  the  requirement  to  use  MIL  standard 
components,  preferably  with  a  second  source. 
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Architectural  and  design  decisions  were  not  influenced 
by  the  risk  of  diminishing  manufacturing  sources 
(DMS). 

As  the  obsolescence  problem  starts  to  become  the 
primary  reason  for  re-designs  and  additional  cost  of 
ownership,  the  obsolescence  issue  needs  to  become  an 
integral  part  of  the  equipment  definition  and 
development  phase. 

It  is  estimated,  that  about  70  to  80  percent  of  the  overall 
product  costs  are  committed  during  the  first  20  percent 
of  the  development  cycle.  Hence,  guidelines  are 
required,  that  pro-actively  address  the  DMS  problem  at 
the  start  of  an  equipment  life  cycle,  when  an  equipment 
architecture  is  defined. 

An  architecture  needs  to  be  established,  that  minimises 
the  re-design  effort  and  duration  once  a  component 
becomes  obsolete.  For  this,  an  ‘open  architecture’  is 
preferred,  that  supports  established  standards.  Obviously, 
such  an  approach  has  the  potential,  to  support  future 
upgrades  driven  by  the  desire  for  performance  and 
functional  enhancements. 

With  the  architecture  being  prepared  for  future 
obsolescence  driven  activities,  the  next  step  is  to  include 
the  issue  of  DMS  into  the  focus  of  the  design  activities 
of  a  new  product.  Use  of  commercial  and  industrial 
grade  components,  life  cycle  projection  and  careful 
environmental  design  are  amongst  the  topics  to  be 
considered  during  the  design  process. 

Both,  architectural  and  design  activities  need  to  be 
embedded  into  a  permanent  obsolescence  management 
process,  that  becomes  part  of  the  project  management. 

MSP2  -  An  Architecture  Proposal 

The  Modular  Signal  Processor  (MSP2)  is  being 
developed  in  a  proprietary  funded  project  that  was 
started  in  1998  at  EADS,  Airborne  Systems  in  Ulm  to 
build  up  a  basis  for  a  family  of  signal  and  data 
processors  for  military  airborne  applications.  It  is  an 
evolution  of  the  MSP  system  that  was  successfully 
applied  in  a  number  of  military  projects.  MSP2  has  now 
successfully  passed  the  acceptance  test  phase. 

A  typical  processor  for  a  military  airborne  application 
consists  of  the  following  MSP2  parts; 

Signal  Processing  Module  (SPM) 

Data  Processing  Module  (DPM) 

General  Purpose  I/O 
Aircraft  Interface 
Fibre  Channel  Network 
Optical  Backplane 

It  is  intended  to  be  a  processing  platform  that  is 
scaleable  in  terms  of  form  factor,  processing  power,  and 
communication  bandwidth.  A  typical  MSP2  system  is 
shown  in  Figure  4. 
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Figure  4:  Typical  MSP2  System 

The  interconnection  between  multiple  Processing 
Modules  (SPMs,  DPMs,  etc.)  is  achieved  by  linking  the 
Fibre  Channel  Interfaces  (FCIs)  of  several  modules, 
either  via  discrete  connections  (coax  cable  or  optical 
fibre)  or  via  an  optical  backplane.  These  links  are  always 
implemented  as  loops.  A  typical  system  consists  of 
several  loops.  The  data  exchange  between  different  loops 
is  done  via  the  Routing  capability  on  the  Processing 
Modules. 

A  Processing  Module  (PM)  consists  of  the  following 
Building  Blocks  (see  Figure  5); 

Processing  Element  (PE) 

Fibre  Channel  Interface  (FCI) 

Module  Support  Unit  (MSU) 

Routing  Network 


Figure  5:  MSP  2  Module  Architecture 

The  first  implementation  of  a  Processing  Element  are  the 
Signal  Processing  Elements  (SPEs)  which  are  currently 
realised  as  PCI  Mezzanine  Card  (PMC)  modules.  Hence 
the  PM  provides  PMC  slots  for  the  mounting  of  the  PEs. 
Off-the-shelf  PMC  modules  may  also  be  mounted  on 
such  a  slot.  Currently,  the  SPE  is  based  on  the  Texas 
Instruments  DSP  TMS  320C6701  which  provides  a 
nominal  throughput  of  1  Gflop. 

The  Module  Support  Unit  consists  of  a  PowerQUICC 
Microprocessor,  associated  memories  and  a  PCI- 
interface  chip.  The  main  functions  of  the  MSU  are:  PM 
management  including  Built-In  Test  (BIT)  and  Fault 
Log,  as  well  as  the  control  of  the  intra-module  data 
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transfer  (between  the  PEs)  and  the  inter-module  data 
transfer  (between  PMs  via  the  FCIs). 

The  Fibre  Channel  Interface  provides  the  external 
interface  to  the  PM.  They  are  either  connected  to  an 
optical  backplane  or  to  discrete  connections  such  as  coax 
cable  or  optical  fibre.  A  first  variant  of  the  FCI  has  been 
produced  as  PMC  module  with  discrete  fibre  connectors. 
Next  generations  will  be  an  integrated  part  of  the 
Processing  Module. 

The  Routing  Network  provides  the  on-board 
interconnections  between  MSU,  all  PEs,  and  the  FCIs.  It 
consists  of  several  PCI  busses  and  PCI  bridges. 

The  Optical  Backplane,  in  conjunction  with  the  optical 
tranceivers  of  the  FCI,  provides  the  board  to  board 
interconnection.  A  combination  of  free  space  and  guided 
wave  transmission  is  realised. 

In  order  to  achieve  a  modular  design,  the  MSP2 
architecture  has  been  structured  into  Building  Blocks 
that  can  be  considered  as  the  smallest  entities  of  the 
MSP2.  In  fact,  by  varying  the  number  of  Building  blocks 
and  the  number  of  modules,  the  MSP2  architecture  is 
scalable  and  can  be  adapted  to  the  needs  of  a  specific 
project.  Those  Building  Blocks  are:  Fibre  Channel 
Interface,  Module  Support  Unit,  and  Signal  Processing 
Element.  They  all  have  a  PCI  bus  interface  in  common. 
Other  Building  Blocks  are  to  be  added  at  a  later  stage, 
e.g.  a  Data  Processing  Element.  Figure  6  depicts  a  family 
tree  of  the  MSP2  architecture  that  show  the  modular 
design  of  it. 


System  level 
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block  level 


MSP2  Processor 

1  Backplane  | 

Module  A  1  1 

Module  B  1  1 

Module  C 

r  ■ 

SPE  1 

FCI  1 

MSU  1 

DPE  1 

Figure  6:  MSP2  Family  Tree 


Software  for  the  MSP2  will  be  organised  in  different 
layer  as  shown  in  Figure  7,  starting  with  the  Board 
Support  Package.  This  layer  not  only  includes  the 
necessary  drivers  but  also  the  system  management 
software  that  organises  tasks  like  power  up,  system 
configuration,  data  transmissions,  and  build  in  test. 

A  COTS  operating  system  forms  the  next  layer,  which 
will  be  separated  from  the  application  software  by  a 
ASAAC  compliant  APOS  layer. 


Figure  7:  Software  Layered  Structure 


Blueprints  are  used  in  order  to  map  the  application  to  the 
MSP-2  hardware.  Blueprints  present  logical  system 
descriptions  using  a  standard  format,  thus  providing  a 
means  for  changing  the  system  characteristics  without 
having  to  change  the  application  or  operating  system 
code.  Blueprints  are  used  for  an  application  specific 
system  design  and  for  run-time  system  configuration 
purposes.  In  detail.  Blueprints  are  broken  down  into  the 
following  three  categories: 

Application  Blueprints  which  formally  describe  an 
application’s  characteristic,  e.g.  its  decomposition 
into  processes,  its  internal  states,  its  performance 
parameter,  its  related  communication  elements. 
Resource  Blueprints  which  formally  describe  the 
logical  representation  of  hardware  resources. 

System  Blueprints  which  formally  describe  system 
integration  and  configuration  decisions  for  a  specific 
implementation  of  an  MSP-2  system.  This  includes 
mapping  information  by  means  of  relations  between 
applications  and  resources,  e.g.  system  state 
transition  tables,  process  scheduling  tables, 
communication  channel  assignments 

Architectural  Features  that  mitigate 
Obsolescence 

Modular  Concept 

Forming  a  modular  structure  as  in  the  MSP2  architecture 
carries  a  number  of  advantages  with  respect  to 
obsolescence. 

The  most  obvious  is  the  efficiency  improvement  during 
the  development.  Once  a  building  block  has  been 
designed  and  tested,  it  can  be  copied  by  a  community  of 
users,  i.e.  the  Module  Designers,  that  do  no  longer  have 
to  repeat  the  same  development  and  verification  tasks. 
This  will  lead  to  a  hardware  design  library  which  can 
grow  and  mature.  This  level  of  modularity  is  achieved  by 
separating  the  operational  functionality  of  a  module  from 
the  actual  hardware  resources/design. 

Once  a  component  on  a  building  block  starts  to  decline 
on  its  life  cycle,  re-design  activities  unavoidably  have  to 
be  started  to  ensure  the  continuing  availability  of  the 
affected  building  block.  However,  in  contrast  to  the  past 
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approach,  that  caused  a  re-design  effort  in  every  instance 
the  obsolete  component  was  used,  the  modular  approach 
allows  to  concentrate  the  effort  on  one  building  block, 
including  test  and  qualification.  Once  the  building  block 
re-design  is  complete,  it  can  be  copied  to  every  module 
that  applies  this  building  block,  with  only  a  moderate 
qualification  effort  on  module  level. 

Applying  a  modular  approach  as  for  the  MSP2  processor 
also  reduces  the  number  of  different  components  used  in 
the  airborne  equipment.  This  allows  to  concentrate  the 
component  selection  process  on  a  reduced  variety  of 
components  and  eases  the  obsolescence  management 
process. 

Standard  Interfaces: 

The  MSP2  architecture  is  based  on  two  interface 
standards.  On  the  modules,  parallel  buses  in  accordance 
with  the  PCI  standard  are  used.  The  primary  interface 
between  modules  is  based  on  the  Fibre  Channel 
standard.  Both  of  these  standards  can  be  considered  as 
well  established  and  ‘state  of  practice’. 

Using  PCI  as  the  standard  interface  of  the  building 
blocks  allows  the  building  blocks  to  be  exchangeable. 
For  example,  a  signal  processing  building  block  can  be 
exchanged  by  a  data  processing  building  block  without 
major  modifications  to  the  rest  of  the  module. 
Encapsulating  hardware  processing  elements  in  that  way, 
using  a  standard  interface,  can  be  considered  as  a 
significant  step  forward  to  an  architecture  that  is 
supportive  with  respect  to  later  obsolescence  removal. 
The  building  block  design  becomes  transparent  to  the 
rest  of  the  module.  Hence,  changes  to  the  building  block 
driven  by  obsolescence,  even  the  exchange  of  a 
processing  chip  set,  are  feasible  without  major  impact  on 
the  rest  of  the  module.  For  example,  the  signal 
processing  building  block  currently  applies  the  TI  C6701 
DSP.  Moving  to  a  different  Signal  Processor  type  if 
required  due  to  obsolescence  or  performance  reasons  is 
considered  to  be  possible  without  affecting  the  MSU. 
Carrying  the  same  idea  one  step  further  results  in  a 
similar  approach  when  it  comes  to  the  application 
software.  Due  to  the  need  for  high  signal  processing 
throughputs,  application  software  in  past  airborne  radars 
was  closely  linked  with  the  available  hardware 
resources.  Algorithms,  requiring  fast  computation,  were 
reflected  in  hardware  designs,  e.g.  ASICs  and  machine 
code  was  used  as  the  most  effective  way  of 
programming  with  respect  to  throughput. 

However,  obsolescence  had  to  be  faced,  not  only  the 
hardware  needed  to  be  modified,  but  also  the  application 
software  was  seriously  affected.  Since  the  signal 
processing  software  development  in  military  airborne 
equipment  such  as  a  radar  can  easily  exceed  one  third  of 
the  overall  development  costs,  safeguarding  this  effort  is 
of  imminent  importance. 

With  more  and  more  powerful  DSPs  and  PowerPCs 
becoming  available,  the  emphasis  of  software 
development  shifts  from  being  effective  in  terms  of 
throughput  towards  the  need  to  reduce  the  software 
development  effort. 


Hence,  the  software  for  the  MSP2  is  organised  in  layers 
as  outlined  above,  in  an  attempt  to  establish  standard 
interfaces.  All  the  different  software  layers,  i.e.  board 
support  package,  operating  system  and  APOS  ensure, 
that  the  hardware  resources  are  transparent  to  the 
application  software.  Moreover,  APOS  ensures,  that 
even  the  operating  system  may  be  exchanged  without 
significant  re-work  of  the  application  software. 

APOS  as  it  was  established  in  the  ASAAC  programme 
translates  the  services  provided  by  an  underlying 
commercial  operating  system  into  a  standard  set  of 
services  that  can  be  used  by  the  application  software. 
Using  standard  interfaces  also  makes  the  use  of  COTS 
products  possible.  In  the  case  of  the  MSP2,  such  COTS 
can  be  a  processing  building  block,  that  interfaces  with 
the  module  via  a  PMC  connector.  Application  of  such 
COTS  modules  can  be  a  solution  when  an  early  A- 
Model  prototype  is  required,  e.g.  to  support  software 
development.  Using  PMC  modules  in  fighter  aircraft 
avionics  is  currently  not  envisaged  due  to  the  high 
vibration  levels  that  occur.  Other  areas  of  COTS 
application  include  the  operating  system  and  software 
libraries. 

As  it  comes  to  test  equipment,  the  use  of  standard 
interfaces  offers  again  an  advantage,  since  readily 
available  COTS  test  equipment  can  more  easily  be  used 
and  more  expensive  STTE  avoided,  for  which  obsolete 
components  would  be  a  problem  again.  Primary  test 
interfaces  of  the  MSP2  are  Ethernet,  Eibre  Channel  in 
conjunction  with  PC,  JTAG  and  a  Eibre  channel  to  VME 
bus  adaptation  in  order  to  open  the  access  to  a  variety 
VMEbus  based  test  equipment. 

As  described  above,  the  decreasing  component  supply 
voltage  level  are  a  primary  source  for  trouble  when  it 
comes  to  obsolescence  driven  re-designs.  As  explained 
in  Ref.  X,  no  standard  voltage  can  be  foreseen  as  in  the 
sense  the  5.0  volts  have  been.  Solutions  to  the  problem 
include  a  dedicated  power  supply  as  part  of  the  re¬ 
design.  However,  this  need  to  fit  into  the  power  and 
cooling  budget  of  the  obsolete  design. 

Eor  a  new  architecture  a  new  approach  is  suggested.  In 
that  the  aircraft  supplied  AC  is  first  converted  to  DC  of 
some  tens  of  volts  in  a  primary  power  supply.  This  is 
then  routed  to  distributed  power  supply  modules,  if  the 
distance  between  the  modules  and  their  total  number 
prohibits  direct  low  voltage  delivery.  DC/DC  voltage 
level  is  performed  and  a  standard  voltage  level  is 
supplied  to  each  module.  There  are  power  supply 
building  blocks  on  each  module,  that  further  convert  the 
voltage  level  to  what  ever  is  needed  by  the  components. 
In  order  to  be  flexible,  the  power  supply  building  block 
output  voltages  are  to  be  programmable  in  a  range  of 
about  1-5  volts.  Care  needs  to  be  taken  of  the 
efficiency  o  such  power  supply  building  blocks,  as  it  is 
likely  to  increase  the  dissipated  heat  of  a  module 
significantly. 
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Design  Features  that  mitigate 
Obsolescence 

Environmental  Issues 

As  outlined  above,  using  commercial  or  industrial  grade 
components  in  a  military  airborne  environment,  e.g.  a 
fighter  aircraft  results  in  a  number  of  environmental 
issues  to  be  addressed. 

The  most  obvious  is  the  temperature  range,  the 
components  have  to  sustain.  Regardless  of  the  cooling 
mechanism,  i.e.  forced  air  cooling  or  convection  cooling, 
the  desired  high  processing  power  per  volume  most 
likely  causes  high  case  temperatures.  Thermal  vias  and 
heat  pipes  are  amongst  the  known  means  to  mitigate  the 
thermal  load  of  hot  components  and  avoid  hot  spots. 
Another  strategy  to  prevent  thermal  stress  from  COTS 
components  is  to  adopt  the  available  processing  power  to 
the  needs  of  the  operation  where  possible.  For  example, 
the  avionics  of  a  fighter  aircraft  might  be  stressed  most 
on  the  ground,  where  no  conditioned  air  is  available,  as 
the  engines  are  off.  In  such  a  situation,  most  of  the 
avionics  equipment  may  not  be  required  to  be  fully 
functional,  except  for  the  cyclic  self  test.  Hence,  the 
majority  of  the  processing  of  the  MSP2  can  be  switched 
to  a  ‘sleep’  mode  with  only  a  fraction  of  the  normal  heat 
being  dissipated. 

A  more  radical  approach  towards  the  use  of  industrial  / 
commercial  grade  components  and  boards  includes 
provisions  to  drastically  soften  the  environmental 
conditions  at  all.  This  may  include  a  ‘hotel  room’ 
environment  which  protects  the  components  from  the 
environmental  extreme.  In  order  to  control  the  thermal 
conditions,  extra  heating  /  cooling  equipment  needs  to  be 
in  place.  At  least  in  military  aerospace  applications  the 
system  designer  is  very  much  confined  with  power, 
weight,  and  volume.  Hence,  a  centralised,  high 
performance  environmental  control  system  is  needed, 
which  also  takes  care  of  humidity.  Other  features  of  the 
hotel  room  environment  include  shock  absorbers  to 
dampen  the  mechanical  stress  from  vibrations  and  shock, 
and  sealed  housing,  to  avoid  the  penetration  of  sand, 
dust,  and  chemicals. 

As  the  humidity  is  beside  cooling  the  most  critical 
environmental  aspect  for  PEM  components,  a  lot  of 
effort  is  put  into  the  development  of  special  coating  of 
critical  components  or  even  a  complete  board.  Recently 
developed  coating  materials  and  processes 
(DaimlerChrysler  Research)  reduce  the  diffusion  of 
water  to  significantly  less  than  10  %  compared  with  un¬ 
coated  PEM  components. 

Providing  a  hotel  room  environment  might  be  an  option, 
where  it  is  permitted  by  the  available  budgets  for 
primary  power,  weight,  and  volume. 

There  is  a  temptation  to  use  commercial  grade 
components  outside  their  environmental  specifications, 
as  they  are  from  the  same  die  as  their  military 
counterparts.  However,  there  is  no  guarantee,  that  this 
will  be  the  case  at  the  next  re-design  and  the  equipment 
designer  will  be  given  no  notification  about  any  change 


in  the  component  production  process,  that  could  cause 
the  component  not  to  perform  at  extended  temperatures. 

Component  Selection 

Throughout  the  MSP2  project,  care  has  been  taken  to 
what  components  are  to  be  used.  Although  commercial 
grade  components  have  been  applied  when  building 
functional  A  Models,  the  design  has  been  driven  by  the 
desire,  to  minimise  the  use  of  commercial  components, 
and  rely  on  manufacturer  with  an  expressed  interest  in 
the  military  market. 

QML  provides  a  performance  based  specification  of 
COTS  components  that  are  designed  to  meet  the  needs 
of  military  applications.  Components  that  fulfil  this 
specification  are  preferred  for  various  reasons:  QML 
components  are  more  likely  to  be  supported  for  an 
extended  period  of  time  compared  to  commercial 
components,  which  are  driven  by  the  dynamic 
commercial  market.  QML  manufactures  also  provide  the 
essential  services  for  an  effective  obsolescence 
management,  e.g.  configuration  control  and  change 
notifications.  QML  devices  work  within  a  broad 
temperature  range,  that  allows  their  application  in 
military  aircraft. 

The  major  drawback  of  going  QML  is  the  restricted 
choice  of  components.  In  fact,  two  of  the  more 
significant  components  used  in  the  MSP2  can  be 
obtained  only  in  a  commercial  temperature  range. 
Amongst  the  options  for  remedy  is  an  up-screening  of 
commercial  components.  However,  this  is  thought  to  be 
a  very  risky  approach,  since  it  is  generally  not  supported 
by  the  original  manufacturer,  which  most  likely  results 
in  a  poor  test  coverage  when  it  comes  to  more  complex 
ICs.  It  will  also  cause  a  liability  problem  if  a  catastrophic 
failure  happens  as  the  IC  manufacturer  nowadays  protect 
themselves  with  disclaimers  for  their  commercial 
products. 

A  more  elegant  approach  is  the  use  of  LPGAs  as  a 
hardware  platform  that  is  more  flexible  and  widely 
available.  VHDL  as  the  programming  language  is  well 
established  and  will  allow  a  design  of  the  required 
functionality,  that  is  for  the  most  part  independent  of  the 
hardware,  provided  that  the  LPGA  provides  the  required 
features  /  performance.  Although,  programming  the 
design  in  VHDL  might  be  initially  more  expensive,  the 
gained  independence  from  a  particular  component 
vendor  might  be  worth  the  effort,  when  it  comes  to 
obsolescence.  Moving  from  one  LPGA  to  the  next 
generation  might  only  require  a  limited  re-design  of  the 
PCB  layout  and  porting  the  VHDL  code.  Hence,  this 
approach  is  not  only  attractive  if  no  component  meets 
the  environmental  specification,  but  also  to  reduce  the 
life  cycle  cost  in  case  of  obsolescence. 

Linally,  when  a  component  needs  to  be  selected,  it  needs 
to  be  considered,  at  what  point  in  its  life  cycle  a 
component  is.  It  is  a  mistake  to  believe,  that  a 
component  has  a  low  risk  of  obsolescence,  if  it  is  at  the 
beginning  of  its  life  cycle.  In  fact,  the  risk  will  be  high 
that  a  newly  introduced  device  will  be  removed  from  the 
market  due  to  e.g.  lack  of  success.  It  is  much  safer,  to 
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choose  components,  that  start  to  be  ‘state  of  practice’, 
especially  for  components  that  affect  the  architecture,  i.e. 
interfaces. 


Conclusion 

System  designer  for  military  avionics  will  be  faced  with 
components  becoming  frequently  obsolete.  This  cannot 
solely  be  longer  solved  by  traditional  methods  including 
last  time  buy.  Frequent  design  updates  will  be  part  of  the 
future  business,  requiring  a  pre-planned  product 
improvement  roadmap. 

In  order  to  reduce  the  involved  effort,  the  EADS  MSP2 
processor  development  has  successfully  applied 
architectural  and  design  measures  right  from  the  start  of 
the  project.  These  include  a  strictly  modular  software 
and  hardware  architecture  and  the  use  of  ‘state  of 
practice’  standards. 

Application  of  commercial  components  is  seen  as  being 
unavoidable,  and  hence  the  creation  of  a  moderate 
thermal  and  mechanical  environment  (i.e.  ‘hotel  room’) 
will  mean  a  major  challenge  for  the  design  of  future 
military  airborne  equipment. 

None  of  the  above  measures  can  solve  the  obsolescence 
problem  on  its  own,  but  needs  to  be  embedded  in  a 
obsolescence  management  process. 
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Summary.  The  example  of  obsolescence  which 
perhaps  comes  most  readily  to  mind  is  that  of 
electronic  components  that  are  no  longer  available. 
However,  this  is  just  a  special  case  of  the  more 
general  form  of  obsolescence  that  arises  when  a 
system  no  longer  provides  an  adequate  solution  to  a 
user’s  problem.  This  may  arise  because  the  problem 
has  changed  or  because  the  solution  (the  system) 
has,  in  some  way.  In  practice,  both  the  problem 
and  solution  are  changing  continuously  and 
asynchronously.  The  approach  to  obsolescence 
management  proposed  here  depends  on  recognising 
and  planning  for  this  change.  In  essence,  it  involves 
looking  forward  to  how  the  demands  on  the  system 
and  the  technology  that  provides  its  capability  may 
both  change.  Simulation  is  a  crucial  tool  in  doing 
this.  In  the  light  of  the  understanding  of  expected 
changes,  the  design  of  the  current  system  is 
arranged  to  facilitate  transition  to  the  modified 
system  and  a  change  plan  is  produced.  This  paper 
also  looks  briefly  at  the  impact  of  the  proposed 
approach  on  the  broader  system  engineering 
activities  and  the  commitment  it  requires  from  the 
system’ s  customer. 

Background  to  Paper.  The  Defence  Evaluation 
and  Research  Agency  (DERA)  is  the  prime  source 
of  research  for  the  UK  Ministry  of  Defence 
(MOD),  and  also  provides  a  major  source  of 
independent  advice  to  MOD  during  all  stages  of 
systems  procurement. 

The  Systems  and  Software  Engineering  Centre 
(SEC)  is  a  relatively  new  body  within  DERA,  being 
established  in  1994  to  act  as  a  focus  for 
professional  software  (and  soon  after,  systems) 
engineering  within  DERA.  The  majority  of  its 
complement  of  about  260  staff  have  an  industrial 
background. 

The  SEC  has  responsibility  for  the  systems  and 
software  standards  and  practices  used  across  DERA 
(which  has  a  staff  of  around  11,000).  It  provides 
the  editor  for  the  draft  ISO  standard  (IS015288)  on 
systems  engineering  and  is  influential  in  setting  the 
systems  engineering  direction  of  MOD's 
procurement  arm,  the  Defence  Procurement 


Agency  (DP A).  It  provides  systems  and  software 
engineering  support  to  a  wide  range  of  programmes 
within  DPA.  The  SEC  is  also  leading  in  the  field 
of  capability  assessment  and  evaluation,  eg  in 
developing  and  applying  various  Capability 
Maturity  Models  (CMMs).  The  author  is  the  SEC's 
Technical  Manager. 

Despite  this  background,  it  should  be  made  clear 
that  this  paper  does  not  constitute  the  results  from  a 
MOD-funded  research  programme,  nor  does  it 
represent  the  official  view  of  MOD,  DERA  or  the 
SEC.  Rather  it  captures  the  personal  views  and 
thinking  of  the  author.  However,  the  author  is 
pleased  to  acknowledge  the  rich  source  of  ideas  he 
has  encountered  in  the  SEC,  DERA,  MOD, 
Defence  Scientific  Advisory  Council  (DSAC) 
working  parties  and  other  contexts. 

Introduction.  Obsolescence  happens  because  the 
world  changes.  Today  ,  this  change  happens  more 
and  more  rapidly.  Sometimes  the  change  is 
predictable  (such  as  the  increase  in  power  of 
processor  chips),  sometimes  it  is  rather  more 
unexpected  and  of  a  more  dubious  nature  (eg,  to 
take  a  completely  different  domain,  the  disruption 
caused  by  the  rapid  rise  -  and  sometimes  rapid  fall  - 
of  "dot  com"  companies  on  the  stock  market). 

Defence  systems  exist  in  this  volatile  world  and  yet 
in  many  ways  are  antithetic  to  it.  They  have  a  long 
"gestation"  period  and  are  expected  to  be  in  use  for 
extended  periods.  It  is  clear  that  a  way  to  mitigate 
the  impact  of  changes  is  required. 

Many  approaches  are  possible,  all  of  which  make 
some  contribution.  Well  known  techniques  include 
attempting  to  create  system  architectures  in  which 
components  can  easily  be  replaced  when 
appropriate,  through  concepts  such  as 
modularisation,  layering,  fixed  and  open  interfaces, 
and  standardisation. 

This  paper  considers  a  complementary  approach 
based  on  simulated  "virtual"  systems.  It  is  a 
generic  approach  that  supports,  but  is  not  restricted 
to,  the  particular  problem  of  managing 
obsolescence  in  electronic  components. 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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The  Nature  of  Obsolescence.  It  is  helpful  to 
consider  some  basic  questions: 

•  What  is  obsolescence? 

•  What  becomes  obsolete? 

•  Why  do  things  become  obsolete? 

Obsolescence.  Obsolescence  is  the  act  of 
becoming  obsolete.  The  dictionary  defines  obsolete 
as  "no  longer  functional".  However,  we  can  extend 
and  clarify  this  by  considering  that  an  item  is 
obsolete  when  both  of  the  following  are  true: 

•  It  no  longer  meets  the  user's  need  (we  assume  it 
once  did!) 

•  It  is  not  possible  to  make  it  do  so  without 
considerable  effort  -  if  at  all 

A  very  simple  case  of  failing  to  meet  the  user's 
need  occurs  when  an  item  ceases  to  function,  and  a 
simple  reason  for  not  being  able  to  remedy  this  in 
an  easy  way  is  if  the  item  is  no  longer  available. 
This  is  the  classic  electronic  component 
obsolescence  situation,  and  is  perhaps  the  easiest  to 
consider,  but  it  is  far  from  being  the  only  way  in 
which  obsolescence  can  occur. 

In  many  cases,  obsolescence  is  a  gradual  process. 
As  time  passes,  it  may  well  be  that  the  item 
diverges  more  and  more  from  what  the  user  needs 
and  at  the  same  time  it  becomes  more  and  more 
difficult  to  bridge  this  gap. 

It  is  also  worth  noting  that  an  item  can  be  obsolete 
in  one  context  (eg  in  respect  to  one  user’s  needs) 
while  not  being  so  in  another. 

What  become  obsolete?  It  is  important  to  note  that 
obsolescence  strikes  at  all  levels,  from  the  smallest 
(electronic)  component  to  a  complete  system. 
Clearly,  if  a  component  becomes  obsolete,  so  often 
does  the  (sub)system  of  which  it  forms  a  part,  but 
equally  a  system  can  become  obsolete  while  each 
of  its  constituents  remains  current  (in  some  context 
at  least).  If  the  collection  of  components  and  their 
interaction  no  longer  provide  the  functionality  and 
performance  required,  and  it  is  not  simple  to 
change  or  directly  replace  them,  then  the  system  is 
obsolete. 

Hardware  components  can  become  obsolete 
because  they  are  no  longer  available  and  cease  to 
provide  the  necessary  features,  either  through 
failure  or  because  more  is  now  needed  of  them  than 
originally.  COTS  software  items  too  can  become 
obsolete  in  the  same  sort  of  way  (although  failure  is 
less  likely).  However,  bespoke  software  can  also 
be  obsolete  if  changing  it,  while  possible  in  theory, 
becomes  too  difficult,  costly  and  risky  to  be 
worthwhile. 

Why  do  items  become  obsolete?  Perhaps  the 
most  obvious  cases  of  obsolescence  occur  within 
electronics.  Anybody  who  owns  a  PC  at  home  is 


only  too  aware  that  even  a  top-of-the-range 
machine  purchased  three  years  ago  is  now  likely  to 
be  considered  out  of  date,  with  little  residual  re-sale 
value.  It  may  still  be  possible  to  do  most  of  what  is 
required  of  it,  but  now  very  slowly  by  today's 
standards.  Virtually  every  item  (processor,  bus, 
memory,  disk,  CD  drive,  etc)  has  seen  significant 
enhancement  over  the  period.  In  some  cases,  there 
are  new  capabilities  that  are  just  not  available  on 
the  "old"  machine  (eg  DVD). 

In  a  lot  of  ways,  though,  the  machine  is  not 
obsolete  because  it  lacks  a  fundamental  capability, 
but  because  it  lacks  enough  of  what  it  does  have 
(not  enough  processor  power,  not  enough  RAM, 
not  enough  disk  space,  not  enough  graphics  speed, 
etc).  Furthermore,  while  in  principle  most  of  these 
aspects  could  be  upgraded,  the  cost  would 
comfortably  exceed  the  price  of  a  brand  new 
replacement. 

And  why  is  what  was  enough  three  years  ago  no 
longer  sufficient?  Largely  because  expectations 
have  increased  -  the  expectations  of  the  end  user 
and  the  expectations  of  the  software  writer,  who 
now  assumes  a  basic  configuration  that  is  valid 
today  but  was  not  so  three  years  ago.  It  is 
interesting  to  note  that  this  software  is  a  COTS  item 
-  so  COTS  is  helping  create  obsolescence  not 
prevent  it! 

Systems  can  also  become  obsolete  because  they 
simply  do  not  provide  the  functionality  that  is 
required  in  a  changing  environment  (if  they  ever 
did!).  Most  changes  in  environment  that  cause 
obsolescence  are  gradual;  the  change  is  continuous. 
However,  some  changes  are  much  more  abrupt. 
Betamax  home  video  recorders  became  obsolete 
very  rapidly  once  the  VHS-Beta  format  battle  was 
lost,  for  example. 

In  addition,  systems  become  obsolete  simply 
because  failures  (primarily  in  hardware,  but 
software  can  be  affected  too)  happen  and  there  is 
no  reasonable  source  of  spares  with  which  to  effect 
a  repair. 

The  poor  owner  of  the  PC  and  the  video  recorder  is 
totally  powerless  to  prevent  his  systems  being  made 
obsolete  by  external,  "wide  world"  forces  over 
which  he  has  no  control.  The  best  he  can  to  do  is 
aim  to  predict  correctly  where  the  future  is  leading 
(eg  VHS)  and  take  reasonable  steps  to  ensure  he 
can  follow  (eg  ensuring  upgrade  potential  in  his 
PC,  such  as  spare  card  slots  and  bays). 

Obsolescence  in  the  defence  world.  Of  course, 
these  same  pressures  and  issues  apply  to  defence 
systems.  They  too  become  obsolete  for  two  basic 
reasons: 

1.  The  environment  in  which  the  system  acts  has 
changed  in  such  a  way  that  it  can  no  longer 
offer  adequate  performance 
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2.  The  system  is  subject  to  faults  that  can  no 
longer  be  repaired  easily  because  of  a  lack  of 
suitable  spares/skills/facilities 

Again,  since  the  defence  world  is  ever-less- 
important  on  a  global  scale  -  particularly  in  the 
most  rapidly  changing  areas  such  as  computing  and 
communications  -  the  obsolescence  may  be 
increased  by  COTS  items. 

Naturally,  the  procurers  and  owners  of  systems  - 
like  the  PC/video  buyer  -  attempt  to  minimise  these 
risks.  However,  the  emphasis  is  often  on  the  initial 
procured  system  and  some  rather  general  upgrade 
capability  (eg  not  consuming  more  than  50%  of  the 
processor  power),  rather  than  on  more  detailed 
forward  planning. 

It  is  not  suggested  here  that  the  future  is  currently 
ignored  when  procuring  a  typical  system,  or  that 
consideration  of  the  future  does  not  get  reflected  in 
non-functional  requirements  such  as  for 
extensibility.  However,  the  approach  outlined  here 
does  perhaps  differ  from  that  widely  adopted  in  its 
emphasis  on: 

•  A  broad  view  of  the  future  that  encompasses 
the  physical  system,  the  user,  the  method  of 
use,  etc 

•  An  in-depth  (at  least  to  the  degree  that  is 
appropriate)  exploration  of  the  future 

•  Explicit  capture  and  maintenance  of  the  future- 
oriented  material 


Planning  for  Change.  Obsolescence  is  caused  by 
change,  and  its  impact  can  only  be  reduced  by 
anticipating  and  accommodating  change.  Change 
is  natural  and  inevitable,  and  it  is  futile  to  ignore  it. 
Procurement  approaches  that  are  predicated  on 
fixed  and  detailed  up-front  system  specifications, 
rigid  fixed-price  contracts,  and  a  fear  of  so-called 
"requirements  creep",  come  close  to  emulating 
King  Canute  \ 

Rather,  the  need  is  to  recognise  change  and  cater 
for  it  from  the  start.  This  change  will  arise  from  a 
number  of  distinct  sources: 

•  The  world  in  which  the  system  is  to  operate  is 
ever-changing.  What  the  user  needs  to  be  able 
to  do,  and  consequently,  what  he  wants  the 
system  to  do  for  him,  will  change  -  perhaps 
slowly,  perhaps  rapidly. 

•  The  technologies  available  for  the  system  to 
exploit  will  change  (for  the  better)  and  what 


*  A  Viking  king  who  commanded  the  waves  to  stop 
coming  up  the  beach  (although  in  fact  he  did  not  actually 
believe  he  could  control  the  waves,  but  wanted  to  show 
that  mortals  are  powerless  over  some  things). 


was  previously  impossible/impractical  will 
become  feasible. 

•  The  user's  perception  of  what  he  wants  of  the 
system  will  change  from  the  very  moment  it  is 
in  use,  even  if  the  rest  of  the  world  were  static. 
Only  when  the  system  is  used  for  real  will 
users  identify  additional  or  different  features 
they  desire. 

The  first  two  points  can  be  addressed  by  actively 
exploring  how  the  possible  problems  (the  first 
point)  and  the  possible  solutions  (the  second  point) 
might  change  in  the  future.  This  is  discussed 
further  below. 

The  last  of  these  points  is  almost  a  separate  issue. 
It  is  what  makes  systems  developments  based  on 
paper  specifications  and  paper  interim  products 
(design  specifications,  etc)  inherently  weak.  It  is 
best  addressed  by  a  development  in  which  end-user 
involvement  is  as  deep  as  possible  throughout; 
there  is  great  emphasis  on  increments  and  iteration; 
and  there  is  maximum  flexibility  to  change 
direction.  In  the  software  world,  disciplined  RAD 
(Rapid  Application  Development)  methods  such  as 
DSDM  (Dynamic  System  Development  Method)^ 
provide  such  a  development  technique. 

Predicting  Change.  We  have  a  number  of  sources 
that  can  help  us  identify  changes  in  both  the 
problem  and  solution  domains,  eg: 

•  The  commercial  world  (which  is  often  only  too 
ready  to  promote  "futureware" !) 

•  Research  programmes,  both  general  and 
defence-oriented 

•  Military  intelligence 

COTS  items  are  likely  to  be  especially  suitable  for 
this  “crystal  ball  gazing”  since  their  developers  and 
suppliers  usually  have  a  well-defined  forward  plan 
for  future  products. 

Some  changes  are  in  fact  very  predictable, 
especially  in  the  solution  domain.  We  know  that 
processors  will  become  more  powerful, 
communication  bandwidth  will  increase,  mobile 
'phone  technology  will  become  ever-more 
sophisticated  (eg  internet  access),  and  so  on. 

Of  course,  the  solution  and  problem  domains  are  by 
no  means  disjoint.  One  impact  of  COTS  is  that 
potential  foes  are  likely  to  enjoy  essentially  the 
same  access  to  COTS  items  as  we  are.  Indeed,  it 
may  be  that  they  are  much  more  agile  in  exploiting 
them  than  some  national  defence  forces.  Hence  a 
potential  solution  may  also  be  a  potential  problem. 


^  See  www.dsdm.org 
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It  is  also  important  to  consider  less  obviously 
predictable  changes.  By  definition,  these  are  more 
difficult  to  identify,  but  "what  if  scenarios  based 
on  the  more  outlandish  of  the  concepts  pursued  in 
research  environments  should  not  be  ignored. 

The  usual  combination  of  "likelihood  of 
happening"  and  "impact"  can  help  guide  the  choice 
of  possible  changes  for  further  consideration. 

Managing  Change.  Combating  obsolescence 
requires  relevant  possible  changes  to  be  studied,  so 
as  to  influence  the  system  as  a  whole  (its  design, 
concept  of  use,  etc)  throughout  its  life. 

For  example,  we  can  consider  a  command  and 
control  system  in  which  data  exchange  bandwidths 
are  much  greater  than  is  currently  achievable,  but 
which  might  reasonably  be  expected  to  be 
attainable  just  a  few  years  after  initial  delivery  of 
the  system. 

It  might  be  that  totally  new  opportunities  for  the 
way  in  which  the  system  is  used  are  opened  up  by 
this  increase  in  capability.  Perhaps  the  user  could 
have  more  or  better  (eg  more  accurate)  information 
available  in  the  same  time,  perhaps  he  could  just 
have  the  same  data  but  much  more  quickly,  or 
perhaps  more  people  could  have  the  same  data. 
Any  of  these  alternatives  might  suggest  a  different 
way  in  which  the  system  might  be  used. 

Other  examples  might  be:  i)  future  technology 
makes  equipment  so  much  more  portable  that  each 
soldier  can  carry  what  now  goes  in  a  vehicle;  ii) 
many  more  users  need  to  be  connected 
simultaneously;  iii)  the  enemy  develops  a  more 
powerful  jamming  capability.  All  these  could  make 
the  current  system  obsolete,  even  if  obsolescence  in 
the  sense  of  component  availability  is  not  an  issue 
at  all. 

At  any  point  in  time,  therefore,  we  have  the 
following  entities  to  consider: 

1 .  The  problem  space^  -  the  environment  in  which 
the  system  is  to  be  used  and  from  which  user 
needs  emerge.  This  is  many-faceted,  covering 
the  full  spectrum  from  physical  terrain  and 
physical  platforms  to  knowledge  and  tactics  of 
all  participants  other  than  the  system  operator. 

2.  The  solution  space  -  the  physical  system  itself 
and  the  way  in  which  it  is  used: 


Figure  1  The  System  in  its  Environment 


Furthermore,  by  looking  ahead,  we  have  two  or 
more  such  pairs: 


Figure  2  The  System  Now  and  in  the  Future 

The  future  view  represents  the  anticipated  system 
and  its  use.  This  vision  of  how  the  system  will  be 
required  to  evolve  forms  a  key  input  into  how  it  is 
designed  now.  Knowing  that  a  system  and/or  the 
way  it  is  used  will  change  in  a  particular  way  in  the 
future  is  a  crucial  piece  of  data  to  inform  the  system 
design. 

Very  broadly,  we  have  a  number  of  inter-related 
aspects  to  consider: 

1 .  The  user  needs  within  an  environment  now 

2.  The  future  user  needs  within  a  future 
environment 

3.  The  system  and  its  use  that  meets  the  needs 
now 

4.  The  future  system  and  it  future  use 

There  are  a  number  of  levels  of  abstraction  at 
which  we  can  consider  all  these  items:  the  problem 
and  solution  domains,  the  user  needs  and  the 
system  that  meets  them,  and  the  system's 
requirements  and  design.  We  can  also  consider 
"the  system"  to  be  the  physical  system,  the  users, 
the  method  of  use,  etc.  These  various  aspects  are 
related  as  shown  below: 


^  Note  that  here  the  "problem  space"  is  not  the  collection 
of  problems,  but  the  context  in  which  the  problem  exists 
and  in  which  the  system  aims  to  provide  a  solution. 
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Figure  3  Solution  and  Problem  Interactions 

The  design  of  the  system  that  is  produced  now  is, 
of  course,  driven  by  the  requirements,  but  in 
addition  -  especially  in  a  COTS-based  system  -  the 
requirements  are  tempered  by  what  is  possible  in 
the  design  and  trade-off  is  needed.  Similarly, 
when  considering  future  needs  and  system 
possibilities,  the  same  relationship  between 
requirements  and  design  exists. 

Also,  the  system  that  we  design  for  the  future  has 
an  influence  on  how  we  design  for  the  present,  so 
that  the  transition  to  the  new  system  is  facilitated. 
On  the  other  hand,  we  need  to  consider  the  current 
design  when  deriving  the  future  system,  for  the 
same  reasons. 

Of  course,  it  may  be  that  in  considering  the  future 
we  decide  that  the  gap  between  the  current  system 
and  the  one  that  is  appropriate  for  the  future  is  so 
great  that  a  continuous  transition  is  not  appropriate 
and  a  better  option  is  to  develop  a  system  with  a 
short  life  and  completely  replace  it  in  the  future. 

A  number  of  forward-looking  horizons  may  be 
appropriate.  For  example,  we  might  look  at  now,  5 
years'  time  and  10  years'  time  and  consider  how  the 
problem  and  solution  might  appear  at  each  stage, 
and  how  to  accommodate  this.  Obviously,  the 
further  into  the  future  the  view  is  taken,  the  more 
approximate  are  likely  to  be  the  various  items  of 
information. 

In  terms  of  the  system  engineering  artefacts  that 
must  be  created,  managed,  etc,  this  approach 
introduces  a  number  of  new  items,  in  addition  to  all 
the  classic  ones  that  exist  when  no  forward  look  is 
taken: 

•  The  requirements  for  the  future  system 

•  The  design  for  the  future  system 

•  A  change  plan  for  the  transition  from  the 
current  system  to  the  future 


The  change  plan  sets  the  way  forward  for  the 
system  based  on  the  predicted  changes  in 
technology  etc  (the  solution  space)  and  needs  (the 
problem  space).  It  may  include  interim  stages 
along  the  path  from  the  current  to  the  future 
positions,  depending  on  how  large  the  current- 
future  gap  is. 

As  with  classic  "point""^  system  design,  traceability 
between  the  design  drivers  and  design  features  is 
important.  Thus,  for  example,  it  is  crucial  to 
maintain  traceability  from  a  particular  design  aspect 
back  to  its  justifying  element  of  the  change  plan. 

The  forward-looking  artefacts  discussed  here 
clearly  need  to  be  maintained  as  time  passes. 
Periodically,  the  assessment  of  future  needs,  future 
solution  options  (eg  new  technological  capabilities) 
and  the  design  for  the  future  system  itself  can  be 
revisited  and  updated  as  appropriate,  resulting  in  a 
revised  change  plan. 

Thus  while  the  system  itself  may  be  essentially 
static  (ignoring  routine  fixes  and  minor 
enhancements),  the  future  system  -  that  is,  the 
envisaged  actual  system,  the  way  it  is  used,  etc  - 
may  be  "upgraded"  more  frequently. 

The  following  diagram  shows  successive  versions 
of  the  physical  and  future  system  with 
asynchronous  upgrades.  The  future  system  bars 
show  the  lifetime  of  various  versions  of  the 
prediction,  not  of  the  actual  system.  Thus,  for 
example,  version  3  of  the  future  system  which  is 
current  when  the  physical  system  is  upgraded  to 
version  2  may  predict  the  position  some  years  after 
version  2  comes  into  service.  Version  3  of  the 
future  system  -  ie  predicted  future  needs  and 
system  design  -  will  influence  version  2  of  the 
physical  system  via  the  relevant  change  plan,  but  it 
is  not  necessarily  true  that  the  introduction  of  a 
modified  system  will  change  the  prediction  for  the 
future,  so  the  future  system  is  not  affected.  What 
must  be  upgraded,  of  course,  is  the  change  plan. 
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Figure  4  Physical  and  Future  Systems 


ie  that  addresses  the  problem  and  solution  at  just  one 
point,  not  across  a  now-future  range 
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Note  that  the  change  plan  is  updated  whenever 
either  the  physical  or  future  system  is  modified. 

Since  in  practice  the  physical  system  is  unlikely  to 
he  totally  static,  the  work  on  revising  the  future 
system  can  inform  and  influence  minor  changes  to 
it. 

The  requirements  and  design  for  the  future  system 
and  the  change  plan  are  products  of  an 
obsolescence  management  activity,  controlled  hy 
an  obsolescence  management  plan.  Related 
activities  to  be  covered  by  the  plan  include 
identifying  the  parts  of  the  system  -  or  problem 
domain  -  that  are  likely  to  be  affected  by 
obsolescence  and  deciding  at  what  frequency  to 
produce  new  versions  of  the  future  system. 

Simulation.  Simulation  of  various  kinds 
(including  here,  for  convenience,  modelling)  is  a 
well-established  tool  to  assist  in  the  development  of 
defence  systems.  Analysis  activities,  such  as 
support  for  balance  of  investment  decisions,  rely 
heavily  on  simulation  to  explore  the  cost- 
effectiveness  of  various  system  options.  More 
generally,  simulation-based  acquisition  is  achieving 
growing  acceptance  and  importance,  allowing  a 
whole  range  of  alternatives  to  be  explored  during 
system  design  and  to  be  validated  during  system 
integration  and  acceptance.  However,  simulation 
specifically  to  address  obsolescence  issues  appears 
to  be  relatively  rare. 

Simulations  that  represent  the  system  as  it  is 
currently  designed,  and  of  the  environment  with 
which  it  interacts,  are  required  to  assist  the 
understanding  of  interfaces,  performance,  emergent 
properties,  etc  during  design,  and  to  aid  integration 
and  validation. 

In  addition,  simulation  is  an  obvious  way  (indeed, 
probably  the  only  way)  to  explore  the  system  and 
its  environment  in  the  future. 

For  designing  today’s  system,  fine-grain,  high 
fidelity  simulations  may  be  needed,  but  the  more 
one  is  looking  into  the  future,  the  more  likely  it  is 
that  coarse-grain,  low  fidelity  simulations  will  be 
appropriate.  Since  such  simulations  are  generally 
quicker  and  cheaper  to  develop,  this  has  the 
advantage  of  making  it  more  feasible  to  explore  a 
number  of  different  variants  of  the  predictions. 

“Broad  brush”  simulations  at  a  relatively  high  level 
of  abstraction  may  well  be  used  during  the  initial 
stages  of  system  development  anyway  (eg  in 
exploring  user  needs  and  in  identifying  options). 


With  suitable  forethought  the  same  simulations 
may  be  exploitable  for  looking  at  future  systems, 
for  example  through  parameterisation. 

Systems  Engineering  Impact.  The  approach 
described  here  introduces  a  number  of  new  systems 
engineering  artefacts: 

•  Obsolescence  management  plan 

•  Change  plan 

•  Future  system  requirements 

•  Future  system  design 

•  Future  simulations  (system  and  environment) 

All  these  require  to  be  seen  as  part  of  the  core  set  of 
systems  engineering  artefacts  for  the  system  and  to 
be  managed  appropriately. 

In  addition,  we  can  see  how  this  approach  affects 
the  systems  engineering  activities.  One  obvious 
impact  is  that  when  the  current  system  changes  in 
some  way,  all  these  new  artefacts  must  be 
examined  and  refined  as  appropriate,  with 
configuration  management  applied.  Traceability  is 
also  a  key  concern. 

The  new  (draft)  ISO  systems  engineering  standard, 
IS015288,  identifies  a  number  of  processes,  as 
shown  in  Figure  5. 

It  is  clear  that  obsolescence  management  has  an 
impact  on  most  of  these  to  a  greater  or  lesser  extent 
and  in  one  way  or  another.  Considering  future 
requirements  and  designs  as  well  as  current  ones 
inevitably  introduces  additional  work  and 
complexity,  which  affects  processes  across  the 
board.  However,  the  major  impact  is  on 
Stakeholder  Needs  Definition,  Requirements 
Analysis,  Architectural  Design  and 
Implementation. 

Stakeholder  Needs  Definition  is  concerned  with 
understanding  what  the  system  must  do,  and 
obsolescence  management  extends  this  to 
considering  future  needs  as  well  as  current/short¬ 
term  ones.  The  future  requirements  will  be 
identified  here  and  this  activity  will  require 
appropriate  simulations  of  the  future  problem 
space. 
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Figure  5  -  ISO  15288  Systems  Engineering  Processes 


Requirements  Analysis  leads  to  a  system 
requirement  based  on  the  stakeholder  needs.  In 
practice,  there  is  often  a  rather  hazy  line  between 
requirements  analysis  and  design  since  often  a 
particular  model  (or  several  models)  of  how  the 
system  might  look  tends  to  emerge  at  this  stage. 
Hence  the  impact  of  future  solutions  may  well  need 
to  be  considered  here,  as  well,  of  course,  as 
considering  future  needs  in  addition  to  current  ones. 

Architectural  Design  is  obviously  very  much 
affected  by  the  need  to  consider  what  solutions 
might  exist  in  the  future  to  cater  for  the  identified 
future  requirements.  Architectural  Design  involves 
trade-off  decisions  between  various  design  options, 
and  this  is  a  key  activity  when  deciding  how  the 
current  design  should  be  influenced  by 
obsolescence  management  issues.  It  is  here  that  the 
future  design  is  derived,  using  appropriate 
simulations.  The  change  plan  will  also  be  produced 
here. 

Implementation  is  concerned  with  taking  the  output 
of  the  Architectural  Design  process  as  a  set  of 
requirements  for  lower  level  sub- systems  and 
repeating  the  analysis  and  design  activities.  In 
practice,  for  large  systems  such  as  an  aircraft,  it 
may  well  be  that  it  is  at  this  stage  that  many 
obsolescence  issues  are  first  studied  in  depth. 
However,  it  is  important  that  their  impact  is 


reflected  upwards.  For  example,  it  may  be  that 
during  the  Implementation  activity,  it  is  decided 
that  a  particular  box  will  be  half  its  current  size  and 
weight  in  five  years’  time.  The  future  aircraft 
design  must  reflect  this  opportunity. 

The  ISO  standard  is  clear  that  the  various  processes 
are  not  necessarily  executed  sequentially.  Even 
ignoring  obsolescence,  iteration  between  the  four 
processes  discussed  here  is  vital,  especially  when 
COTS  is  being  exploited.  The  approach  described 
here  can  be  seen  as  introducing  a  parallel  iteration 
between  requirements  and  design  for  the  future 
system,  and  between  the  current  and  future 
systems,  as  shown  in  Figure  6. 

It  is  interesting  in  passing  to  note  that  while  the 
ISO  standard  certainly  does  not  preclude 
obsolescence  management  as  described  here,  it 
makes  no  explicit  mention  of  catering  for  it.  Its 
focus  is  on  maintaining  the  system  as  first  delivered 
and  reacting  to  new  needs  as  they  arise,  rather  than 
predicting  new  needs  and  solutions.  It  is  reactive 
rather  than  proactive. 

Procurement  Impact.  A  very  obvious  impact  of 
this  approach  is  that  it  involves  extra  effort,  cost 
and  time,  compared  with  simply  ignoring 
obsolescence.  This  is  a  major  issue  since  it  seems 
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all  too  common  that,  for  a  variety  of  reasons,  solutions.  There  are  obviously  very  complex  trade- 

investment  in  “up  front”  activities  for  systems  is  offs  and  decisions  to  he  made ! 

difficult  to  obtain. 


Figure  6  Iteration  Within  and  Between  Systems 


The  amount  of  effort  that  it  is  appropriate  to  put 
into  obsolescence  management  clearly  depends  on 
the  risk  of  obsolescence  and  its  expected  impact.  In 
this  way,  obsolescence  is  no  different  from  any 
other  factor  influencing  the  system.  The  overall 
risk  management  for  the  system  should  include 
assessing  obsolescence  risks  and  deciding  upon  the 
appropriate  degree  of  forward  planning.  However, 
it  is  clear  that  the  necessary  effort  could  well  be 
significant. 

Since  obsolescence  arises  from  the  problem  domain 
as  well  as  the  solution  domain,  this  is  obviously  an 
issue  that  should  be  considered  by  the  user/procurer 
at  a  very  early  stage.  It  is  not  driven  solely  by 
aspects  of  equipment  obsolescence  and  cannot  be 
considered  as  something  to  be  left  to  the  system 
supplier  alone.  The  approach  adopted  may  have  a 
major  impact  on  the  system’s  through-life  cost 
profile. 

Neither  is  it  a  matter  simply  of  cost  and  possibly 
timescales.  It  may  be  that  analysis  shows  that  to 
address  an  anticipated  obsolescence  problem,  the 
initial  system  should  have  characteristics  that 
would  be  considered  sub-optimal  if  the  system 
were  not  to  be  upgraded.  Thus  initial  users  might 
be  asked  to  accept  sub-optimal  performance  now  to 
provide  a  better  (or  perhaps  simply  cheaper)  system 
later  -  based  on  predictions  of  future  needs  and 


Conclusion.  Obsolescence  in  systems  has  many 
causes,  but  ultimately  is  due  to  change  in  the 
problem  space  and/or  the  solution  space.  By 
attempting  to  understand  the  nature  of  this  change 
for  any  given  system,  we  can  facilitate  adapting  to 
it.  This  requires  the  future  system  requirements  and 
design  to  be  derived,  and  a  change  plan  to  transition 
from  the  current  to  future  system  to  be  produced. 
COTS  elements  may  be  particularly  amenable  to 
this  kind  of  forward  looking  since  they  often  have  a 
predictable  development  path. 

Obsolescence  must  be  a  major  element  of  the 
system’s  risk  management  and  this  will  decide  the 
degree  of  investment  that  is  appropriate.  There 
may  also  be  major  issues  involved  in  trading  off 
immediate  functionality  to  facilitate  future  changes. 
Procurer  commitment  to  this  approach  is  therefore 
vital. 

Simulation  will  play  a  major  role,  especially  in 
assessing  future  needs  and  solutions.  These 
simulations  and  the  various  other  artefacts  (future 
design,  etc)  become  key  systems  engineering 
products  and  must  be  managed  accordingly.  The 
"whole"  system  becomes  the  traditional  physical 
system,  its  design,  etc  plus  these  other  items. 

It  is  clear  that  this  approach  is  non-trivial. 
However,  to  at  least  ask  for  all  systems  the  question 
“how  much  of  this  should  we  do?”  seems  to  be  vital 
in  reducing  the  impact  of  obsolescence. 
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Abstract: 


This  paper  reports  on  the  advanced  techniques  employed  in  the  specification  of  software  requirements  and  the 
subsequent  software  development  for  an  E-Scan  demonstrator  Radar  Data  Processor.  This  involves  the  Rapid  Object- 
oriented  Process  for  Embedded  Systems  (ROPES)  [1],  UML  syntax,  object-oriented  design,  and  automatic  code 
generation  and  test. 

The  COTS  technology  reported  is  in  terms  of  commercially  available  state  of  the  art  method  and  tool  support  for  the 
software  analysis  and  design.  The  resulting  software  product  contains  a  significant  proportion  of  COTS  code  resulting 
from  the  code-generation.  We  are  also  using  automation  in  development  of  our  MMI,  a  COTS  GUI-builder,  and  COTS 
hardware  and  operating  system. 

In  this  paper  we  also  report  on  the  object-oriented  method,  using  the  ROPES  process,  together  with  information  about 
how  in  practice  we  are  implementing  the  theory.  We  present  the  structure  of  the  software  and  how  it  relates  to  the 
application  under  development. 

With  these  techniques  there  are  significant  reductions  in  obsolescence  due  to: 

■  customer  visibility  and  understanding  of  the  product  under  procurement,  making  clear  the  advantages  and 
limitations  of  what  will  be  produced, 

■  development  of  a  coherent,  consistent  and  maintainable  system  specification, 

■  use  of  use  an  industry-standard  model  notation  (UML)  to  capture  the  analysis  and  design,  enabling  portability  of 
the  design  to  other  tools  and  products, 

■  flexibility  in  catering  for  evolving  requirements, 

■  development  of  testable  requirements,  enabling  original  functionality  to  be  re-checked  after  addition  of 
enhancements, 

■  techniques  for  enabling  the  re-use  or  replacement  of  modules  with  defined  interfaces, 

■  easy  and  maintainable  connections  between  specification  and  implementation, 

■  high  initial  quality  and  low  rework  costs. 

This  paper  will  be  of  benefit  to  those  just  embarking  on  system  and  software  development,  or  considering  updating 
processes  in  a  legacy  project.  It  is  also  applicable  to  those  just  embarking  on  choice  of  tools  and  methods  for  initiating 
programmes  as  well  as  for  early  feasibility  studies. 


Keywords:  System  Specification,  Requirements  Analysis,  Real-time,  UML,  Object-oriented,  Analysis,  Design, 
Modelling,  Code-generation 


1  Introduction 

The  E-Scan  radar  project  is  aimed  at 
producing  a  flying  demonstrator  of  an 
electronically-scaimed  phased-array  antenna. 
It  will  be  fully  capable  of  tracking  targets 
and  will  provide  some  advanced  features 
such  as  adaptive  beamforming,  but  will  not 
include  the  full  range  of  functionality  of  a 
system  such  as  the  Captor  Radar  integrated 
with  the  Euro  fighter  Typhoon  weapon 
system. 

The  Trials  Monitor  Computer  (TMC)  is  the 
main  processor  in  the  radar  and  is 
responsible  for  the  signal  and  data 


processing,  as  well  as  controlling  the  activities  of  other 
subsystems  such  as  the  antenna  and  the 
receiver/exciter.  The  TMC  consists  of  two  main  areas: 
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the  Signal  Processor  (SIP)  is  largely  for  handling  the 
flow  of  digital  data  from  the  receiver  and  processing  it 
continuously  to  obtain  events  relating  to  target 
detections;  the  Data  Processor  (DAP)  is  event-based, 
creates  tracks  of  targets  from  the  detections  and 
manages  the  distribution  of  RF  power  radiated,  and  has 
an  MMI  for  controlling  other  functions. 

Both  SIP  and  DAP  use  predominantly  COTS 
hardware,  with  commercial  operating  systems  and 
development  tools. 

This  paper  relates  to  the  DAP. 


environment.  The  tool  vendor  is  increasing  the  number 
of  target  platforms  supported  as  market  forces  dictate. 

An  early  decision  to  purchase  consultancy  and  training 
on  both  tools  and  methods  has  proved  to  be  very 
fruitful  and  well  worth  the  outlay. 

2.2  Using  UML 

The  UML  is  a  notation  that  has  evolved  from  Software 
Development.  Some  of  the  tools,  such  as  Use  Case  and 
Sequence  Diagrams  are  specifically  aimed  at  creating  a 
realistic  model  of  what  the  customer  wants. 


2  Technical  Details 

2.1  State  of  the  Art  Software  Tools 

At  the  outset,  the  decision  was  made  to  invest  in 
technology  to  reduce  the  cost  and  timescales  of 
software  development.  This  approach  is  key  to  making 
a  successful  demonstrator  in  a  short  period. 

The  tools  have  to  provide  analysis  and  design  support, 
starting  from  requirements  with  a  clear  path  through 
the  design  to  automatic  generation  of  code  from  the 
design  (not  just  code  frames).  To  validate  the  design, 
simulation  is  essential  and  the  testing  support  must 
enable  verification  of  the  generated  system  behaviour 
against  that  defined  in  the  requirements. 

From  the  handful  of  tools  that  met  our  basic 
requirements,  we  chose  the  I-Logix  Rhapsody  tool, 
which  provides  for  full  UML  analysis  and  design,  code 
generation  and  automatic  verification  against 
scenarios. 

Our  core  tool  set  consists  of  Rhapsody  (analysis, 
design,  simulation,  verification),  DOORS 
(requirements  tracking)  and  ClearCase  (configuration 
management).  Although  from  different  manufacturers, 
these  tools  provide  useful  integration  and  have  been 
found  to  work  well  together.  Supporting  these  are  the 
usual  set  of  C-n-  compilers,  host  support  (the  Wind 
River  RTOS  VxWorks)  and  other  productivity 
enhancements  (See  Figure  2). 


Figure  2 

From  an  obsolescence  perspective  the  capability  of  the 
Rhapsody  tool  to  select  a  target  environment  is  of 
particular  importance.  As  target  platforms  become 
obsolete  the  tool  has  a  number  of  platforms  that  can  be 
selected  and  the  code  regenerated  for  that  particular 


Previously,  the  specification  of  requirements  have  been 
expressed  as  “Victorian  novel”  text  -  often  disjointedly 
spread  across  a  number  of  documents  -  combined  with 
a  collection  of  algorithms  and  little  consultation  with 
the  software  engineers  responsible  for  implementation. 

This  has  often  been  followed  by  what  is  described  as 
the  “over  the  wall”  approach  where  the  requirements 
are  passed  to  the  software  engineers  and  the  systems 
engineers  move  onto  something  else.  Large  amounts  of 
software  development  effort  is  then  spent  rewriting  the 
contents  of  the  requirements  documents  into  a 
Software  Requirements  Specification  (SRS).  This 
process  is  illustrated  in  figure  3. 

The  traditional  approach  leads  to  a  number  of 
problems: 

1.  Generation  of  the  requirements  is  difficult  to 
manage. 

2.  Traceability  to,  and  Verification  of,  the 
requirements  is  difficult  to  achieve. 

3.  Maintenance  of  the  requirements  is  expensive. 

4.  Software  is  difficult  to  develop. 

5.  Changes  in  requirements  (which  are  accepted 
as  inevitable)  are  difficult  to  implement. 


Customer 

Specification 

_ 

Systems 


Figure  3 
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The  approach  we  have  adopted  for  the  DAP  is  to  have 
an  integrated  systems-software  team  (see  figure  4)  and 
a  closely  coupled  SRS/ACD  pair  (see  figure  5).  This 
approach  is  detailed  below 

Requirements  Analysis  (from  the  ROPES  perspective) 
is  performed  using  Use  Cases,  Sequence  Diagrams  and 
Statecharts.  The  Requirements  Analysis  results  in  a 
functional  decomposition  of  the  DAP,  the  details  of 
which  are  captured  in  the  Software  Requirements 
Specification  (SRS).  The  Use  Case  descriptions  give 
the  functional  details  of  the  system  in  a  textual  manner, 
that  will  be  utilised  later  in  identifying  objects,  with  the 
sequence  diagrams  defining  the  Use  Case  behaviour  in 
a  dynamic  manner. 


Algorithmic  Definition  is  carried  out  based  on  this 
functional  decomposition  of  the  system,  which  is 
agreed  early  in  the  project  lifecycle  by  the  integrated 
systems-software  team.  The  algorithms  are  described 
using  Activity  Diagrams  to  show  the  blocks  and  flow 
of  algorithmic  activity  with  references  to  mathematical 
formulae  and  textual  descriptions  as  appropriate.  This 
detail  is  captured  in  an  Algorithm  Control  Document, 
which  supplements  the  SRS. 

By  using  the  same  functional  decomposition  for  both 
documents,  it  becomes  easier  for  the  software  team  to 
understand  which  algorithms  are  required  to  implement 
a  particular  area  of  functionality  (i.e.  a  use  case). 

The  development  of  the  SRS  and  the  ACD  are  iterative 
in  nature  and  can  allow  details  of  algorithmic 
implementation  to  be  fleshed  out  much  later  in  the 
lifecycle  than  would  normally  be  the  case.  One  of  the 
benefits  to  this  approach  is  early  introduction  of 
software  engineering  effort  to  the  process  which 
removes  the  lengthy  delay  whilst  algorithms  are 
“fully”  defined  by  systems  engineers  before  software 
development  starts. 

Links  between  the  SRS  and  ACD  enable  the  two 
documents  to  give  a  detailed  and  co-ordinated 
description  of  the  System.  Using  hypertext  links,  an 
engineer  or  customer  can  navigate  around  the 


requirements  with  ease.  Both  the  SRS  and  ACD  are 
embedded  in  the  DOORS  Requirements  Traceability 
tool. 

With  the  creation  of  a  closely  coupled  SRS/ACD  pair  a 
detailed  definition  of  the  system  exists  that  can  be  well 
understood  by  those  using  it.  This  is  the  first  step  to 
ease  of  maintenance  and  the  resulting  reduction  in 
overhead  costs.  Generally,  maintenance  of  systems 
documentation  (inevitable  in  light  of  changing 
requirements)  is  complicated  by  a  poorly  defined  set  of 
requirements  that  are  scattered  across  a  number  of 
documents  that  have  little  or  no  real  relationship.  By 
ensuring  that  the  Specification  is  easily  understandable 
(using  UML)  and  well  laid  out  (and  thus  easily 
navigable)  the  impact  of  change  can  be  quickly 
assessed  and  is  less  onerous  to  implement. 


Figure  5 


2.3  Systems-Software  Integrated  Teams 

Experience  has  shown  that  unless  the  systems  engineer 
understands  the  process  by  which  their  specification 
(itself  another  interpretation  of  the  customer 
requirements)  is  implemented  the  systems-software 
review  process  is  prone  to  failure.  (Sometimes  the 
systems-software  relationship  goes  the  same  way.) 

With  the  use  of  a  common  language  of  understanding 
that  is  intuitive  in  its  usage  these  two  problems  can  be 
alleviated.  The  fact  that  Use  Case,  Sequence  Diagrams 
and  Activity  Diagrams  are  simple  concepts  to 
understand,  powerful  in  their  capability  for 
representing  complex  requirements  and  are  now  widely 
accepted  as  a  way  of  describing  requirements  means 
that  the  Software  Engineers,  who  invariably  pioneer 
these  new  methods,  can  achieve  “buy-in”  from  the 
systems  engineers. 

For  this  relationship  to  be  successful,  it  is  essential  that 
the  systems  engineering  team  are  given  the  appropriate 
training  in  the  development  methodology  and 
sufficient  time  to  review  the  software  work  products  - 
particularly  the  Object  Analysis  (both  structural  and 
behavioural). 

On  the  DAP,  systems  engineers  receive  the  same 
training  in  software  methodology  and  tools  as  the 
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software  engineers.  A  core  team  is  formed  which 
allows  very  close  inter- working  to  take  place  on  a  level 
playing  field.  This  enables  the  software  engineers  to 
bring  their  experience  into  the  development  of  the 
system  specification  whilst  allowing  the  systems 
engineers  a  greater  understanding  of,  and  input  to,  the 
software  development  process  in  the  subsequent  phases 
of  the  lifecycle. 

In  particular,  the  integrated  team  work  together  to 
create  the  software  object  analysis  model.  This  co¬ 
operation  helps  the  software  team  to  understand  the 
requirements  and  means  the  systems  team  will 
understand  how  the  software  will  implement  the 
requirements.  During  the  creation  of  this  model,  the 
integrated  team  can  ensure,  at  an  early  stage,  that  the 
software  will  implement  the  requirements  and 
algorithms  stated  in  the  SRS  and  ACD. 

2.4  Flexibility  with  Evolving 
Requirements 

As  stated,  the  DAP  is  being  developed  using  the 
ROPES  process.  This  is  an  iterative/incremental  means 
of  software  development  using  the  Spiral  Lifecycle. 

Use  Case  analysis  gives  a  functional  decomposition  of 
the  system.  In  our  application  each  Use  Case  has  been 
identified  as  an  “Iterative  Prototype”. 

These  prototypes  are  taken  through  the  full  software 
lifecycle  to  produce  working  software.  This  gives  a 
great  deal  of  scope  for  risk  reduction  in  the  early  stages 
of  a  programme  by  allowing  working  code  to  be 
developed  for  a  target  platform.  The  choice  of  which 
prototypes  should  be  developed  first  is  based  on  risk 
impact  assessment. 

The  additional  benefit  is  that  the  prototype  is  re- 
useable,  in  so  much  as  it  is  a  building  block  to  be  used 
in  the  incremental  development  of  the  application. 

By  careful  consideration,  based  on  risk  reduction  and 
introduction  of  required  (phased)  functionality,  the 
application  is  developed  incrementally  by  the 
integration  of  the  prototypes. 

By  adopting  this  development  process  there  are  two 
main  areas  of  benefit  in  respect  of  flexibility. 

The  algorithmic  development  can  continue  during  the 
software  development  process  for  agreed  areas  of 
functionality  within  the  system  (i.e.  Use  Cases  that 
may  be  implemented  later  in  the  programme).  The  Use 
Cases  and  Scenarios  give  the  functional  structure,  or 
framework,  of  the  system  under  development  at  an 
early  stage.  This  allows  the  OO  development  to 
progress  to  the  detailed  design  phase  before  the 
algorithms  must  be  completed. 


In  developing  functional  prototypes  and  quickly 
reaching  the  stage  where  executable  software  is 
running  on  a  target  (much  earlier  than  in  traditional 
developments),  problems  with  requirements  can  be 
fed-back  quickly  and  avoiding  action  taken.  The 
prototype  may  be  re-iterated  and  re-incorporated  in  the 
application  to  include  the  changed  requirement. 

2.5  Requirements  Testability 

Although  the  combination  of  Use  Cases  and  Sequence 
Diagrams  gives  a  powerful  means  of  specifying  the 
requirements  there  is  an  additional  benefit  to  the 
creation  of  Sequence  Diagrams.  The  use  of  Sequence 
Diagrams  implicitly  forces  engineers  to  address  the 
issue  of  testing  the  functionality  being  defined.  This  is 
as  applicable  for  lower  level  integration  test  (for  sub¬ 
system  use  cases)  as  it  is  for  high-level  system 
acceptance  testing  (system  use  cases). 

On  the  DAP  we  use  the  Rhapsody  CASE  tool  to  carry 
out  automated  Sequence  Diagram  comparison.  That  is, 
the  Sequence  diagrams  specified  can  be  compared  with 
those  generated  by  the  actual  model  created  to  fulfil 
the  requirements. 

2.6  Connecting  Requirements  through  to 
Design  Models 

The  analysis  of  requirements  is  carried  out  by  first  of 
all  defining  the  Use  Cases  (i.e.  the  particular  areas  of 
functionality)  as  shown  in  figure  6.  The  Use  Cases  are 
initially  just  headlines,  but  are  rapidly  filled-out  with 
scenarios;  there  will  typically  be  a  number  of  Sequence 
Diagrams  for  each  use  case,  showing  the  functionality 
in  specific  situations  (see  figure  7). 
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System  Wrap  Test 

GOAL/PURPOSE: 

Perform  the  Radar  system  wraparound  communication  BIT  lest. 

TRIGGER  EVENT :  do  Radar  Wraparound  test  request  from  Engineering  Display  operator 
PRECONDITIONS:  The  CAR  radar  is  in  a  ’Standby'  or  Operative  State. 

POSTCONDITION: 

Success  End  -'Wraparound  Test  Ok'  message  is  indicated  on  the  Engineering  Display. 

Failed  End  -  Test  failed  or  timeout.  'Wraparound  Test  Fail'  message  and  the  cause  of  failure 
shall  be  indicated  on  the  Engineering  Display. 

MAIN  SUCCESS  SCENARIO 

See  Message  sequence  diagram  'MSC_Sys_Wrap' 

EXTENSIONS 

tbd 

EXCEPTIONS 

1  .No  response  from  any  LRIs  within  TBD  milli  seconds  ,  Initial  policy  is  to  abort  operation 
and  report  a  fault .  In  the  future  a  recovery  sequence  (soft  reset  LRI  and  retry  a  max  of  2  times) 
may  be  implemented. 

PERFORMANCE  (Quality  of  service) 

Priority:  Low.  Any  radar  activity  in  progress  should  be  allowed  to  goto  completion. 

Performance  :  Test  done  within  100  millisecond. 

Frequency:  Periodic  -  execute  during  a  Resource  Frame  BIT  slot  (  0.5  Hz) 

Episodic  -  execute  Wraparound  Bit  test  on  operator  request 


Figure  6-b 
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Figure  7 

At  this  level,  the  analysis  is  very  much  in  terms  that  a 
customer  would  understand  -  we  are  in  the  favourable 
position  of  being  both  pseudo-customer  (writing 
requirements  on  behalf  of  the  actual  customer)  and 
contractor  (implementing  those  requirements),  so  we 
have  been  able  to  make  sure  that  the  analysis  correctly 
echoes  the  requirements. 

A  key  advantage  is  that,  because  the  Use  Cases  and 
Sequence  Diagrams  are  captured  in  the  Rhapsody  tool 
(subsequently  used  for  detailed  design)  and  linked 
back  to  source  requirements  in  DOORS,  requirements 
are  traceable  to  the  implementation. 


which  brings  together  a  number  of  the  best  practice 
lines  of  thought,  specialised  for  real-time  applications. 

The  first  stage  in  this  is  to  define  preliminary 
“subsystems”,  which  are  in  effect  collections  of 
functionality.  Each  use  case  is  placed  into  a  subsystem 
-  the  use  cases  are  decomposed  to  such  a  level  as  to 
ensure  that  each  use  case  is  in  only  one  subsystem, 
though  the  subsystems  will  often  contain  more  than 
one  use  case. 

In  figure  8,  “Radar  Control”,  “Burst  Control”  and 
“Tracker”  are  the  subsystems  within  the  “DAP”. 

The  subsystems  and  their  identified  artefacts  are 
defined  as  the  “Physical  Model”.  This  is  captured  in 
Rhapsody  by  a  Physical  package  (shown  in  Fig.  1 1). 

The  often-difficult  borderline  between  function-based 
specification  and  object-based  implementation  is 
encountered  at  this  point:  the  implementation  of  the 
use  cases  is  by  domain  classes  instantiated  in  the 
subsystems. 


Figure  8 


2.7  Moving  From  Functionality  to 

Objects:  Domains  and  Subsystems 

The  methodology  used  on  this  project  is  Rapid  Object- 
Oriented  Process  for  Embedded  Systems  (ROPES), 


Subject  Matter  Separation,  one  of  the  useful  aspects  of 
the  Shlaer-Mellor  methodology  has  been  imported  into 
ROPES,  in  the  form  of  domains.  Within  a  domain  are 
collected  all  the  objects  that  relate  to  a  particular 
subject  matter  (e.g.  I/O,  alarms,  tracking).  These  are 
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an  orthogonal  set  to  the  subsystems:  all  objects  are  in 
fact  defined  in  domains,  but  are  “used”  in  the 
subsystems.  The  collection  of  domains  identified  is 
referred  to  as  the  “Logical  Model”.  This  is  captured  in 
Rhapsody  by  a  Logical  package  (shown  in  Fig.  11). 

A  domain  diagram  (figure  9)  shows  the  inter¬ 
relationships  between  the  domains: 

Project:  AMSAR  CAR 
Author:  J.S.Chita 
CreationDate:  14/Dec/99 
Purpose: 

-Domains  context  diagram 
showing  all  the  domains  and  their 
dependencies. 

«Usage»  «Usage» 

«Usage» 


via  an  Ethernet  bus.  Normally  in  a  single  processor 
system  the  2  subsystem  communicate  with  each  via  2 
associations  links  using  asynchronous  events: 

1)  MessageRouterController->iEngDisplay. 

2)  EngDisplayController->iDapCommand. 

These  associations  for  the  distributed  processor  are 
then  realised  using  a  combination  of  2  patterns  (figure 
10): 

1)  The  Proxy  pattern  provides  location  transparency. 

2)  Eorwarder  -  Receiver  implements  the 
interprocessor  communication  between  the  2 
subsystems. 


— 1 

d Radar 


dBurstManagement 

dBIT 

«Usage»  «Usage» 


dInputOutput 


«Usage» 


dHwAbstraction 


Eigure  9 

Although  it  would  in  principle  be  possible  to  follow 
the  Shlaer-Mellor  project  organisation  model  and  have 
domain  specialists,  we  have  chosen  to  avoid  the 
potential  for  boredom  in  team  members  by  dividing 
work  by  subsystem  and  use-case  rather  than  domains, 
though  we  retain  an  element  of  domain-ownership  to 
ensure  consistency. 

2.8  From  Analysis  to  Design 


jPtoiecI:  AMSAR  CAR 

jCrealicinDate:  lO/Aug^ZClOO 
j  Purpose: 


Eigure  10 


2.10  Units  of  Re-use 

To  achieve  reduction  in  obsolescence,  we  must  identify 
the  specific  units  that  are  available  to  be  re-used.  The 
aim  is  to  be  able  either  to  extract  these  units  to  be  used 
in  a  new  system,  or  to  be  able  to  replace  units  of  the 
current  system  when  changes  in  functionality  are 
required. 


The  dilemma  encountered  with  elaborational  methods 
is  that  one  may  lose  sight  of  the  analysis  after  adding 
design  information.  The  high  level  objects  are  created 
only  in  order  that  the  use  cases  and  their  sequence 
charts  may  be  defined  and  do  not  take  account  of 
whatever  is  found  necessary  for  the  detailed  design. 

One  solution  that  has  been  proposed  is  to  keep  two 
models,  the  original  analysis  model  and  the  design 
model  (as  elaborated).  The  difficulty  with  this  is 
keeping  the  two  models  synchronised. 

The  alternative  is  to  continue  with  a  single  model  thus 
reducing  analysis/design  consistency  issues.  If  one 
utilises  the  idea  from  ROPES  that  several  “views”  of 
the  model  can  exist  then  one  can  show  purely  analysis 
views  from  which  the  design  views  are  subsequently 
created. 

2.9  Implementing  Distribution 

Shows  how  distribution  is  implemented  when 
subsystems  are  located  on  separate  processors  linked 


We  have  identified  two  main  areas  of  re-use: 

a)  Subsystem  Re-Use,  when  exactly  the  same 
functionality  (i.e.  the  same  Use  Cases)  is  required 
in  a  new  system,  or  when  the  complete  set  of 
functionality  is  to  be  replaced  with  new 
functionality  in  the  current  system.  The  subsystem 
is  a  convenient  unit  of  re-use  as  it  instantiates  all 
the  classes  it  needs  to  operate  (it  can  be  seen  rather 
as  a  PCB  in  hardware  terms).  When  a  subsystem  is 
moved  to  another  place,  only  its  external 
interfaces  need  to  be  observed  and  attached  into  its 
new  surroundings.  This  is  done  in  practice  by 
setting  up  relationships  to  defined  interface 
classes  for  inputs  to  the  subsystem  and  initialising 
the  relationships  from  within  the  systems  for  its 
outputs.  Both  the  identity  of  the  interface  class  and 
the  initialisation  of  output  relationships  are 
available  as  public  operations  on  the  subsystem. 

b)  Domain  Re-Use,  when  classes  in  a  domain, 
originally  designed  to  implement  a  different  set  of 
Use  Cases,  can  be  re-used  to  create  a  new 
Subsystem.  The  domain  classes  can  be  seen  as  a 
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“toolbox”  available  to  implementers  of  Use  Cases, 
who  are  encouraged  by  publication  of  the  domain 
services  to  pick  classes  from  there  rather  than 
invent  new  classes.  The  benefits  of  the  design 
patterns  will  automatically  be  achieved  when  the 
classes  are  used  in  a  new  Subsystem  to  fulfil  the 
Use  Cases  of  that  Subsystem.  This  can  be  a  more 
difficult  level  of  re-use  to  achieve,  because  the 
implementer  of  a  Use  Case  may  identify  slightly 
different  requirements  for  the  classes  than  those  in 
the  “toolbox”  -  but  by  careful  management 
maximum  use  of  existing  classes,  with  inheritance 
to  provide  for  small  variations,  can  be  achieved. 

Because  our  development  method  clearly  identifies 
both  subsystems  and  domains  in  the  artefacts 
generated,  we  have  a  head-start  on  achieving  re-use. 


3  Results 

We  have  found  the  Rhapsody  tool  and  the  ROPES 
method  to  fit  well  into  our  environment.  The 
requirements  analysis  has  provided  a  sound  baseline 
for  the  object  oriented  analysis  and  design,  which  is 
proceeding  well.  One  additional  benefit  is  that  we  can 
now  provide  to  our  partners  in  the  project  not  just 
paper  documentation  of  the  design  but  also  animated 
simulation  prototypes. 

By  using  a  UML-based  method  we  have  also  found  it 
easy  to  bring  new  recently-graduating  members  into 
the  team,  making  use  of  the  training  in  object-oriented 
techniques  that  now  commonly  forms  part  of  software 
engineering  courses. 
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We  have  utilised  the  concepts  of  the  Physical  and 
Logical  models  to  develop  the  software  application  [2]. 
The  Physical  model  defines  the  system  to  be 
implemented,  the  logical  model  captures  the  domains 
which  themselves  contain  the  essential  building  blocks, 
or  classes,  of  the  system. 

The  System  package  contains  the  System  Actors  and 
the  Subsystem  architecture  identified  during 
Architectural  design. 

The  Build  package  contains  the  incremental  builds  and 
is  effectively  the  instantiation  of  the  Physical  model. 


3.1  First  Prototype 

Our  first  prototype  is  based  on  a  wrap-test  of  the 
system,  which  runs  a  communication  check  on 
simulations  of  the  other  subsystems.  We  took  this 
prototype  all  the  way  from  requirements  through  use 
cases  to  detailed  design,  implementation  and  test. 

The  following  diagram  shows  a  “browser”  view  of  the 
system  package  structure.  The  domains  have  names 
starting  with  “d”  and  are  captured  in  the  Logical 
package,  the  subsystems  “s”  and  are  captured  in  the 
Physical  package. 


Ligure  11 


3.2  Physical  Model:  Object  Model 
Diagram 

The  objects  involved  in  a  use  case  can  be  shown  on  an 
object  model  diagram  for  a  particular  subsystem: 


Pro|ect:  AMSAR  CAR 
AuthorJ.S.Chita 


Ligure  12 
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3.3  Logical  Model:  Active  Class  3.6  Build  Model:  System  Instantiation 

The  implementation  of  the  behaviour  of  the  active  Shows  the  classes  used  to  build  up  the  DAP  system  for 

classes  is  generally  shown  in  a  state  chart;  standalone  testing  on  the  PC  development  host. 


evDoSubsySenWraprea/  *  doingAntWraptea... 


sysHoHDap 


:EngDisplay_ucSysWrapTestStub 


iDisplayMessageRouter 

«subsystem» 


^  PowerUpandBITManagement 
«subsystem» 


Figure  16 

The  wrap-test  has  proved  successful  not  only  as 
confirmation  of  the  tool  and  method  choice,  but  also  as 
the  first  real  prototype  that  implements  part  of  the 
functionality  of  the  full  system. 


4  Conclusions 

Software  represents  a  large  and  increasing  proportion 
of  the  costs  of  current  systems.  Current  high  software 
costs  for  almost  every  project  indicate  that  this  is  an 
area  where  reduction  of  obsolescence  and  increase  of 
re-use  must  be  introduced  if  costs  for  future  systems 
are  to  remain  within  limited  budgets. 

While  the  object-oriented  approach  provides  a  basic 
framework  for  encapsulating  functionality  to  provide  a 
theoretical  possibility  for  re-use,  it  does  not  of  itself 
provide  the  key  advantage.  Simple  insertion  of  object- 
oriented  analysis  and  design  into  a  company’s 
processes  does  not  provide  all  the  advantages  that 
could  be  obtained,  some  companies  finding  little 
benefit. 

To  take  full  benefit  from  object-oriented  techniques,  a 
coherent  method  of  capturing  the  requirements  in  a 
customer-visible  way,  analysing  those  requirements  to 
provide  the  basis  for  the  design,  managing  the  key  step 
from  functionality  to  objects  and  building  up 
functionality  with  prototypes  must  be  used. 

We  are  convinced  that  our  use  of  the  ROPES  method 
with  advanced  tool  support  will  enable  us  to  build  up 
software  matching  the  requirements,  to  maintain  that 
software  as  requirements  evolve,  and  to  re-use 
significant  parts  of  the  software  in  new  systems  having 
requirements  in  common. 


aartSubSystemTeaO; 


evSi  pWrapTeaDone/ 
delate  itsWrapData:  ' 

U  send  results  of  Wrap  tea  to  RRM  for  reporting  to  Eng  Display 
itaBitResponss->GEN(evSub^aamWrapTeaResult(ltsSubsyaemWrapTeaResult)); 

doingRxWraptea... 


doingSIpWraptea... 


Figure  13 

3.4  Build  Model:  Usecase  Instantiation 

Shows  the  classes  used  to  build  up  the  use  case. 


ilO.ucSysleirWrapTeatSlub 


fleceiirerlOjjcSystemWrapTesIStuD 


iSIplO.ucSystemWrapTesIStub 


Figure  14 

3.5  Build  Model:  Subsystem 
Instantiation 

Shows  the  classes  used  to  build  up  the  sub-system. 


PowfUpandBrrWanaaemTit 


iSSWrapTest 

«lruarface» 


ItsSSWrapTestManagerll 


;SSWrapTestManager 


itsRxWrapFaultReport  1 


:HxWrapFaultHepOrt  I 
_ ItsAntWrapFaultRepory  ’ 

I  AntWrapFaultReport  | 

itsSipWrapFaultRepofty'* 

I  SipWrapFaultReport 

ItsSubsvstemWrapTestResult'i' 


£ubsystemWrapTestResult 

ItsWrapData 
I  WrapData 


itsBITManager  1 
I  :BITManager 


ItsBITScbedulejl  itsBITResult  1 

fltTSonedule  BITResult 


Project:  AMSAR  CAR 
Author:J.S.Chita 
CreationDate:  16/Dec/99 
Purpose: 

-Shows  the  object  initialisation  for 
host  testing  of  TestMode. 


Figure  15 
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Abstract 


The  upcoming  Software  Radios  wiii  change  the 
commercial  as  well  as  the  military  market  of  radio 
communications.  Due  to  their  programmability 
Software  Radios  offer  an  extreme  flexibility  falling 
into  3  main  domains:  Multirole,  Multimode  and 
Multiband  operation.  Multiband  just  means  that  the 
radio  can  cover  the  complete  spectrum  from  HF  to 
SHF,  Multimode  requests  to  cope  with  different  air 
interfaces  and  Multirole  addresses  the  question, 
which  applications  a  software  radio  has  to  serve. 
Essential  properties  of  a  software  radio 
architecture,  particularly  supporting  the  use  of 
COTS  components  and  mitigating  parts 
obsolescence,  are  the  strict  decoupling  of 
application  software  and  platform  hardware 
(forming  APIs)  together  with  a  consequent 
modularization  of  the  hardware.  The  decoupling 
allows  hardware-independent  development  of  the 
application  software,  whilst  the  hardware 
modularization  supports  a  cyclic  reengineering 
process  in  case  components  have  to  be  replaced 
by  new  COTS  parts.  Savings  in  term  of  logistic  and 
upgrades  reduce  the  overall  life-cycle  costs  by 
about  40  percent  in  comparison  with  conventional 
radios.  In  turn,  these  platforms  are  free  to  be  scaled 
to  manpack,  airborne,  naval  or  stationary 
deployment,  simultaneously  optimised  for  example 
in  terms  of  power  saving,  size  or  flexibility,  where 
the  software  layer  guarantees  interoperability 
among  these  radio  families  by  common  waveforms. 
An  example  of  an  existing  military  software  radio  is 
presented  showing  multiband,  multimode  and 
multirole  features. 


Components,  once  selected  in  the  design  process, 
have  been  available  for  many  years  and  one  could 
expect  that  there  are  suppliers  for  these 
components  active  on  the  market  even  after  a  long 
period  of  time.  On  the  other  hand  waveforms  and 
transmission  methods  in  the  military  as  well  as  in 
the  civil  world  have  been  stable  for  years.  The 
technical  progress  was  low  compared  with  today 
and  military  technology  was  regarded  nearly  always 
to  be  ahead  of  civil  technology. 

As  we  all  know  times  have  changed.  Today 
components  like  microprocessors  double  their 
performance  within  a  few  years.  As  a  consequence 
obsolete  components  tend  to  vanish  from  the 
market.  But  not  only  components  are  getting 
obsolete.  Driven  by  civil  communications 
technologies  like  GSM,  TETRA,  UMTS  or  Wireless 
LAN  military  people  have  to  face  the  fact,  that  in 
many  cases  they  do  not  have  equipment 
comparable  with  civil  equipment  in  performance 
any  longer.  The  capabilities  of  military  equipment 
are  getting  obsolete  too.  It  has  to  be  expected  that 
this  trend  will  speed  up  in  the  future. 

The  effects  of  this  trend  are  that  life  cycle  cost  are 
increasing,  lifetime  is  decreasing  and  there  is  a  time 
lag  of  military  technology  compared  with  civil 
technology.  On  the  other  hand  military  logistics 
require  equipment  to  be  stable  and  to  survive  even 
if  technology  is  setting  the  pace. 

Means  and  concepts  have  to  be  found  to  fight 
these  effects.  One  of  these  concepts  is  the 
Software  Radio  technology. 

How  can  Software  Radio  Technology  contribute  to 
mitigate  obsolescence  and  life  cycle  cost? 


Introduction 


In  former  days  radios  for  military  applications  often 
have  been  supportable  for  25  to  30  years. 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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The  User’s  Need  interoperation  with  civil  authorities  with  their 

dedicated  frequency  bands  and  civil  waveforms. 
This  shall  be  performed  without  exchanging  assets 
In  times  of  decreasing  military  budgets  the  cost  as  far  as  possible, 
factor  is  one  of  the  most  important  issues  for  the 
user.  Life  Cycle  Cost  is  a  suitable  figure  to  express 
the  overall  cost  for  the  user. 


Life  Cycle  Costs  consist  mainly  of 
•  Purchasing  costs 


Multiband,  Multimode,  Multirole 


Maintenance  support  costs  (including  spare 
parts) 

Test  equipment  costs 
Transportation  and  handling  costs 
Training  costs 
Facilities  costs 
Documentation  costs 


Life  Cycle  Cost  shall  be  optimised  in  sum. 


Changing  boundary  conditions  like  altered  military 
strategies  and  tasks  (e.g.  peace  keeping 
operations)  finance  flow  or  upcoming  new 
waveforms  require  the  possibility  to  update  or 
upgrade  the  equipment.  Update  means  to  improve 
the  equipment  maintaining  the  same  functionality, 
whilst  upgrade  means  to  increase  the  functionality 
e.g.  by  adding  new  waveforms,  options  or 
interfaces.  It  is  highly  desirable  to  perform  update 
and  upgrade  by  software  download  means  only. 
Changing  the  hardware  or  software  configuration 
calls  badly  for  an  efficient  configuration 
management.  The  user 
needs  to  know  the  actual 
status  of  the  hardware  or 


As  for  multiband  operation,  a  Software  Radio 
should  cover  a  maximal  frequency  range  starting 
from  HF  (about  1.5  MHz)  up  to  several  GHz 
because  of  various  reasons:  The  increasing 
demand  for  information  exchange  and  its  involving 
broadband  waveforms  are  facing  sharply  limited 
frequency  resources  and  are  shifting  applications  to 
higher  currently  not  used  frequency  ranges. 
Secondly,  each  country  has  its  individual  frequency 
assignment  scheme.  Finally,  ITU  refarming 
procedures  place  civil,  commercial  communication 
in  formerly  military  occupied  frequencies.  GSM  or 
the  security  service  system  TETRA  for  example 
covers  a  broad  range  of  frequencies.  Therefore, 
multiband  operation  is  of  extremely  importance  to 
cope  with  mobility  requirements  across  international 
borders. 

Frontend  modularity  helps  to  extend  frequency 
bands  in  the  future.  Experience  shows  that  the 
broader  the  covered  frequency  band  the  more 
challenging  it  is  to  maintain  performance  over  the 
whole  band. 

A  software  radio,  however,  must  not  place 
unrealistic  demands  on  linearity,  image  rejection, 
dynamic  range  and  interference  reduction.  From 
the  current  technology  point  of  view  some  analog 


software  implemented. 


In  the  past  each  waveform 
or  transmission  method  had 
its  own,  dedicated  equip¬ 
ment.  The  new  global 
political  context  increases 
international  operations  like 
humanitarian  aid,  peace 
keeping  and  peace  forcing 
tasks.  Interoperability 

between  different  nations 
using  different  military 
waveforms  will  be 
mandatory  in  the  future. 
Equipment  must  be  able  to 


Multiband 


Multimode 


lultirole 


Multiple  Frequency  Bands 
HF  1.5 -30  MHz 
VHF  30-  174  MHz 
UHF  225  -  400  MHz 
UHF  400  -  2000  MHz 
TETRA  bands 
Frontend  modularity 
Colocation  issues 


Preplanned  Product  Impr. 


Multiple  Air  Interfaces 

Civil  waveforms 

TETRA,  GSM,  UMTS, 
AM,  FM,  VDL... 

Military  waveforms 
FSK,  HQ,  SATURN, 
L11,L22,  JTIDS... 

High  data  rate  waveforms 

COMSEC/TRANSEC 

TDMA,  FDMA,  CDMA 


Preplanned  Product  Impr. 


Multiple  Applications 

Radio  Terminal,  Relais, 
Base  Station,  Data 
Link,  Civil,  Military 

Handheld,  Mobile, 
Airborne,  Stationary 

Point  to  Point,  Point  to 
Multipoint,  Broadcast 

Voice,  data,  video 

Different  Interfaces,  Proto¬ 
cols,  Rem.  Control 

Preplanned  Product  Impr. 


be  switched  between  Figure  1:  Multiband,  Multimode,  Multirole 

different  waveforms.  Huma¬ 


nitarian  aid  requires  also 
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pre-processing  by  mixing  and  fiitering  heips  a  iot  to 
meet  requirements  in  terms  of  power  consumption, 
size  and  coiiocation  performance. 

Multimode  operation  requests  the  Software  Radio 
to  be  compliant  with  various  air  interfaces. 
Throughout  the  civil  world  there  exists  a  large 
number  of  different  standards,  e.g.  GSM  in  Europe, 
IS-95  and  AMPS  in  the  US  and  there  will  be  no 
convergence  of  wireless  standards  in  the  future  due 
to  political/commercial  (see  for  UMTS)  and 
technical  reasons.  Amplitude  Modulation  (AM), 
frequency  modulation  (FM)  and  frequency  shift 
keying  (FSK)  are  still  widely  used  legacy 
waveforms.  Digital  modulation  schemes  like  QPSK, 
OMSK  and  D8PSK  are  required  by  modern 
waveforms. 

In  the  military  area  there  are  various  NATO 
standards  and  proprietary  waveforms  in  use.  Often 
there  is  a  requirement  to  switch  from  one  waveform 
to  another  either  due  to  tactical/operational  or  due 
to  maintenance  reasons  (switch-in  of  a  backup 
unit). 

Multirole  operation  addresses  the  question,  which 
applications  a  software  radio  has  to  serve.  Besides 
the  capability  to  handle  voice,  data  and  video 
transmission  a  Software  Radio  has  to  answer  to 
different  operational  scenarios  particularly  placed 
by  different  roles.  These  operational  scenarios 
influence  the  choice  of  line  interfaces,  line  protocols 
and  remote  control  concepts. 

Combat  Net  Radio  (CNR),  Radio  Access  Point 
(RAP),  Relay  and  Data  Link  are  typical  applications 
a  military  Software  Radio  must  meet. 
It  has  to  be  scalable  from  handheld  with  stringent 
power  consumption  requirements  over  airborne 
equipment  (optimised  in  size),  manpack  up  to  a 
base  station  with  several  communication  lines  in 
parallel.  Besides  typical  hierarchical  networks 
(between  mobile  and  base)  mobile  radios  should  be 
able  to  establish  links  among  themselves,  like 
TETRA's  direct  mode.  A  Software  Radio  has  to 
cope  with  lots  of  different  access  and  network 
control  schemes,  introduced  by  advanced 
supplementary  services  (e.g.  Access  Priority, 
Dynamic  Group  Assignment,  Late  Entry,  Remote 
Disable/Enable)  or  redundant,  multi-hierarchy 
networks.  That  applies  to  fixed  networks  such  as 
ISDN/PSTN,  LAN,  WAN  and  to  moving  networks  on 
the  air  as  well.  A  Software  Radio  should  be  able  to 
establish  point-to-point  and  point-to-multipoint  links 
and  to  provide  broadcast  services. 
Consequently,  there  is  a  need  to  build  radio  families 
based  on  scalable  platforms  to  meet  the 
requirements  in  terms  of  size,  weight  power, 
functionality  and  performance. 

The  core  feature  across  the  multiband,  multimode 
and  multirole  properties  is  Preplanned  Product 
Improvement  (PPPI).  The  design  target  is  to 


foresee  prerequisites  for  future  extension  and 
improvement  of  the  radio.  A  vast  majority  of 
improvements  can  then  be  performed  my  sole 
means  of  software  download. 


Software  Radio  Architecture 


One  of  the  key  elements  of  Software  Radio 
Architecture  is  the  strict  separation  of  the 
applications  (software)  from  the  hardware  platform 
by  horizontal  architecture  layering.  This  principle, 
which  is  well  known  from  PC  technology,  offers  a 
well  defined,  hardware  independent  interface  (API) 
to  the  software  (see  Figure  2). 


Typically,  the  Software  Radio  Architecture  is 
functionally  partitioned  into  different  modules 
interconnected  by  Radio  Control  Buses  (RCBs). 


Application 

API  (Application 
Programming  interface) 

Hardware 

Figure  2:  Separation  of  Appiications  from 
the  Hardware  Piatform  (Horizontai  Approach) 


Waveform 


Operating  system 


Radio  piatform 


Analog  to  the  ISO/OSI-model  we  can  distinguish 
between  channel  processing,  modulation 
processing,  bitstream  processing  and  network 
processing  (Figure  3). 


Channei  processing  includes  amplification, 
filtering  on  RE  and  IF  level,  RE  switching,  RE 
matching,  mixing,  AGC/ALC  (automatic  gain 
control/  automatic  level  control)  etc.  Processing  is 
done  on  analog  and  digital  levels. 

Modulation  processing  (or  waveform  processing) 
is  dealing  with  all  kind  of  manipulation  and 
managing  of  the  signal  like  modulation  and 
demodulation,  equalisation,  digitisation,  symbol 
tracking. 

The  module  bitstream  processing  performs 
operations  on  bit  level.  Those  are  e.g.  forward  error 
correction,  interleaving  and  ciphering.  In  context 
with  ciphering  red/black  separation  has  to  be  taken 
into  account  if  necessary. 
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Network  processing  includes  the  Media  Access 
Control  (MAC)  functionalities,  routing,  and  network 
management. 


The  modules  in  Figure  3  show  the  horizontal 
layering  as  in  Figure  1,  separating  hardware  and 


high-performance  Software  radios.  Contrary  to 
conventional  radios  with  fixed  architecture  the 
M3TR  features  maximum  flexibility  in  terms  of 
frequency  bands,  waveforms  and  functions 
satisfying  the  requirements  of  various  user 
domains.  M3TR  is  not  restricted  to  military 
networks,  but  serves  via  loading  the  appropriate 


Antenna 


Radio  Control  Bus 


Signal 
I/O  Source 


Figure  3:  Typical  Software  Radio  Architecture 


software  parts  from  each  other.  The  software 
incarnated  by  DSPs  and  programmable  FPGAs 
holds  the  control  over  the  main  operating 
parameters  and  offers  an  extreme  flexibility  with 
benefits  in  both  commercial,  security  services  and 
military  applications.  Moreover,  due  to  well  defined 
and  standardised  interfaces  between  the  modules, 
which  prepare  some  kind  of  "open  architecture", 
modules  can  be  simply  plugged  into  or  moved  away 
from.  As  a  result  the  radio  platform  is  scalable  to 
e.g.  handheld,  manpack  or  base  station 
applications.  This  optimisation  in  terms  of  power 
saving,  size  or  flexibility  is  of  particular  importance, 
since  hardware  components  represent  a  bottleneck 
in  terms  of  radio  performance.  The  software  driven 
hardware  platform  allows  an  easy  implementation 
of  advanced  waveforms  and  functions. 

A  software  radio  must  not  place  unrealistic 
demands  on  e.g.  A/D  and  D/A  converters  by  direct 
digitising  at  the  RF  stage  (from  the  current 
technology  point  of  view).  Instead,  some  trade-offs 
are  essential.  Digitisation  usually  takes  place  on  the 
first  or  second  IF.  This  allows  to  relieve  the  A/D 
converter  from  excessive  demands  for  the  dynamic 
range. 


Example  of  an  Existing  Software 

Radio 

The  M3TR  (Multimode  Multirole  Multiband  Tactical 
Radio)  represents  a  completely  new  generation  of 


software  also  as  a  terminal  in  civilian  PMR 
(Professional  Mobile  Radio)  networks. 

By  forecasting  technology  trends  the  platform  is 
designed  in  advance  to  cope  with  future 
applications,  frequency  ranges,  additional  functions 
and  future  COTS  products.  Evolutionary  updating  of 
modules  fully  exploits  the  technological  advance  of 
semiconductors  and  keeps  the  radio  up-to-date,  an 
implementation  of  the  ETSI  standard  TETRA  for 
example  is  planned.  In  fact,  software  configurability 
and  upgradability  by  Pre-Planned  Product 
Improvement  (PPPI)  is  a  key  asset  of  a  modular 
hardware  and  software  architecture  in  order  to 
reduce  technology  refresh  insertion  time  and  to 
lower  costs. 


The  two  manpack  transceivers  MR3000H  and 


Figure  4:  Example  of  an  Existing  Software 
Radio  (M3TR) 
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MR3000U  providing  seamiess  coverage  of  the 
transmission  range  from  1.5  MHz  up  to  108  MHz 
(modei  H)  and  from  25  MHz  up  to  512  MHz  (modei 
U)  form  the  core  of  the  M3TR  transceiver  famiiy.  In 
totai,  both  units  are  designed  for  transmission  and 
reception  from  1.5  MHz  to  512  MHz.  So,  with  just 
two  transceivers  (MR3000H  and  MR3000U),  the 
M3TR  transceiver  famiiy  covers  the  whoie  spectrum 
from  short  wave  through  to  the  UHF  band. 

Thanks  to  optimised  protocols  and  waveforms 
M3TR  attains  high  data  rates  for  digital  voice,  real¬ 
time  video  and  visual  display  data.  Beyond  Line  of 
Sight  (BIOS),  e.g.  HF  offers  up  to  5.4  kbps  user 
rate  per  3  kHz  channel,  while  in  the  Line  of  Sight 
(LOS)  case  VHF/UHF  provides  up  to  64  kbps  per 
25  kHz  channel  suited  for  real-time  data,  video  and 
Internet  /  Intranet  access  via  the  radios  integrated 
Ethernet  interface.  In  command  systems  this 
ensures  among  other  things  automated  data 
exchange,  for  example  for  online  position  display 
and  data  distribution.  PPPI  (Pre-Planned  Product 
Improvement)  ensures  to  subsequently  integrate 
planned  and  future  methods  in  the  equipment 
through  simple  software  upgrades. 

Different  communications  standards  exist  even 
within  NATO  and  new  ones  are  still  being  prepared. 
Examples  are  HAVE  OUlCK  I  and  II,  SATURN  for 
UHF  or  STANAG  4444  for  the  shortwave  band. 
Export  waveforms  like  the  Rohde  &  Schwarz 
proprietary  waveforms  SECOM  and  SECOS  can 
easily  be  implemented.  As  a  software-defined  radio, 
M3TR  can  be  made  compatible  with  almost  all 
existing  EPM  (Electronic  Protection  Measure) 
radios.  It  is  interoperable  with  legacy 
communication  systems  and  supports  growth  for 
new  requirements. 


The  use  of  open  system  standards,  like  TCP, 
Ethernet,  and  well  defined  interfaces  within  the 
radio  makes  M3TR  scaleable  to  match  the 


communication  requirements  of  different  users  and 
furthermore  extendible  to  support  further  growth 
and  changes. 

Comprehensive  multirole  features  allow  its  easy 
integration  into  communication  networks,  e.g.  as  a 
functional  terminal  in  a  subnet,  e.g.  CNR  (Combat 
Net  Radio:  voice  and  data  semi-duplex 
transmission  in  combat  networks)  or  PRN  (Packet 
Radio  Net:  multi-hop  functionality  for  packet  data 
transmission,  adaptive  routing  of  messages  in  case 
of  jamming  or  relocation).  But  M3TR  can  also  act 
as  an  interface  between  the  subnets,  REN  (Range 
Extension  Node:  for  user  voice  and  data  services 
established  among  radios  out  of  range).  Playing  the 
role  of  a  RAP  (Radio  Access  Point)  M3TR 
establishes  the  interface  to  fixed  networks,  e.g. 
ISDN/PSTN,  LAN,  WAN,  and  standardised  bus 
systems,  e.g.  RS485,  and  to  data  interfaces,  e.g. 
RS232,  RS422  and  MIL-STD-188-1 14A.  It  also 
offers  intelligent  gateway  and  relay  functions. 


Commercial  off  the  Shelf  (COTS) 

In  the  past  there  were  good  reasons  for  military 
people  to  buy  special  Mil-equipment  instead  of  civil 
products.  Today  there  are  no  doubts  that  the  trend 
to  make  greater  use  of  COTS  products  does  make 
sense  particularly  as  user  budgets  are  limited. 
However  a  careful  analysis  is  necessary  to  optimise 
the  user’s  benefit  arising  from  this  trend. 

“Just  buying  COTS”  does 
not  necessarily  secure  all 
of  the  benefits  they  might 
bring  to  the  development, 
maintenance  and  cost  of 
systems.  There  arise 

some  problems  and 

sources  of  risk  by  the  use 

of  COTS  products.  First, 
COTS  products  may 

commit  the  user  to 
proprietary  interfaces  and 
solutions  that  are  not 
common  with  any  other 
product,  component,  or 
system.  Secondly,  many 
security  service  systems 
have  a  25-  to  35-year 
lifetime,  while  the  average 
COTS  component  today 
may  be  upgraded  every  6 
to  12  months.  Thus  any  money  that  is  saved  by 
procuring  a  COTS  product  with  proprietary 
interfaces  will  quickly  be  lost  in  maintenance  and 
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Figure  5:  Multiband,  Multimode,  Multirole  Properties  of  the  M3TR 
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logistics  as  products  and  interfaces  change  without 
the  ability  to  migrate  cost-effectively  to  other 
products  and  other  technologies  in  the  future.  This 
situation  becomes  even  worse  when  the  vendor 
stops  supporting  the  product  without  any 
substitutes. 

So  the  question  is  not  “Shall  we  buy  COTS?”  but 
instead: 

“How  can  we  make  use  of  COTS  to  optimise  our 
Life  Cycle  Management?” 

It  makes  sense  to  subdivide  the  COTS  question 
into  four  areas: 

COTS  equipment,  COTS  modules,  COTS 
components  and  COTS  communication  protocols. 

Buying  COTS  Equipment  only  is  useful  in  special 
cases,  where  the  services  provided  by  civil 
technology  fit  well  the  user’s  need  concerning  the 
type  of  service,  availability,  maintainability  and 
security.  Examples  may  be  GSM,  TETRA,  UMTS 
and  SATCOM.  Problem  areas  can  be  proprietary 
interfaces  and  logistic  aspects. 

COTS  Modules  (or  subsystems)  providing  special 
functions  can  be  integrated  e.g.  into  a  radio  unit. 
This  appears  to  be  a  useful  approach  for  wireless 
LANs,  modems  or  chip  sets  for  dedicated 
waveforms  like  TETRA  or  GSM.  TETRA  for 
example  represents  a  typical  system  developed  for 
professional  users.  These  COTS  products  are 
available  at  reasonable  costs.  The  chip  sets  are 
optimised  in  terms  of  size  and  power, 
simultaneously  making  re-engineering  for  software 
dispensable  and  cutting  down  the  required 
development  effort.  The  main  challenge  is  that 
COTS  modules  very  often  have  proprietary 
interfaces,  which  cannot  be  influenced  without 
loosing  the  cost  advantage. 

The  most  efficient  area  of  use  of  COTS  in  military 
applications  is  that  of  COTS  Components. 
Semiconductor  elements  like  A/D-  converters  (often 
said  to  determine  the  bottleneck  of  a  software 
radio)  and  DSPs  are  roughly  doubling  its 
performance  every  2  years.  Keeping  up  Third-Party 
DSP-libraries  are  available  at  reasonable  costs. 
Radio  suppliers  have  been  analysing  part  samples 
in  terms  of  reliability,  performance  and  critical 
parameters.  Industry  programs  have  shown  the 
rightness  of  this  approach.  COTS  parts  reduced 
material  cost  by  up  to  50  %,  increased  part 
availability  by  tenfold  and  achieved  reliability 
equivalent  to  military  parts. 

Another  important  aspect  is  to  make  use  of  COTS 
Communication  Protocois  like  TCP/IP,  UDP  and 
X.25.  This  addresses  the  question  of  infrastructure, 
often  underestimated  in  terms  of  complexity  and 
cost.  If  commercial  available  protocols  are  used 
possibilities  arise  to  stick  on  commercial  available 
equipment  like  TCP/IP  routers,  switches. 


multiplexers  etc.  This  will  reduce  system  cost 
considerably. 

The  requisite  to  use  COTS  components  is  an 
essential  part  of  the  Software  Radio  concept.  In 
advance  the  platform  is  designed  to  cope  with 
future  applications,  frequency  ranges,  additional 
functions  and  COTS  products  in  the  future.  An 
internally  "open"  architecture  with  stable  interfaces 
between  the  modules  makes  it  possible  to  cope 
with  the  frequent  fluctuations  in  COTS  products  and 
keep  the  radio  adaptable  to  advances  in  technology 
and  changes  in  the  marketplace. 

The  'plug-and-play'  idea  let  an  update  be 
accomplished  through  replacing  old  components 
with  new  products  the  marketplace  supplies.  In  fact, 
this  idea  introduces  an  evolutionary,  cyclic 
process  with  a  constant  system  change  (Figure  6). 
In  a  cyclic  process  the  products  from  the  COTS 


COTS  Module 

Market  Update 


Figure  6:  Evolutionary  Cyclic  Development 
Process 


market  are  evaluated  with  respect  to  their 
technological  advances  e.g.  in  terms  of  signal 
processing  power  and  power  consumption  and  then 
integrated  into  the  system  (module  update). 
Evolutionary  and  cyclic  updating  of  modules  fully 
exploits  the  technological  advance  of  semi¬ 
conductors  and  keeps  the  evolvable  system  up-to- 
date.  There  will  be  no  unexpected  “vendor  lock”. 

Typical  examples  for  this  cyclic  process  arise  from 
the  permanent  improvement  of  A/D  converters  and 
Digital  Signal  Processors  (DSPs).  In  more  or  less 
periodic  intervals,  determined  by  the  user  or  market 
needs,  a  re-engineering  of  the  modules  containing 
the  A/D  converter  or  the  DSPs  is  performed. 
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Conclusion 


The  increasing  speed  of  technoiogy  progress 
especiaiiy  on  semiconductor  component  ievei  and 
the  drasticaiiy  reduced  product  cycie  wiii  cause  a 
severe  obsolescence  problem  of  military  radios. 
Life  Cycle  Management  is  getting  more  and  more 
difficult. 

To  mitigate  this  problem  the  Software  Radio 
approach  is  an  appropriate  solution. 

Key  is  first  to  provide  a  horizontal  approach,  which 
means  to  establish  a  sharp  separation  between 
application  (software),  and  hardware  (radio 
platform).  This  property  of  the  radio  architecture 
allows  development  of  application  software  running 
independently  from  the  hardware  configuration. 
The  second  key  point  is  consequent  and 
transparent  hardware  modularization  which  enables 
to  replace  functional  hardware  modules  in  a  cyclic, 
ongoing  process: 

Whenever  components  are  obsolete  a 
reengineering  of  a  particular  module  can  be  done 
which  replaces  the  existing  module  by  a  new 
module,  which  makes  use  of  newer,  more  powerful 
and  eventually  cheaper  components. 
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1.  Summary 

Considering  obsolescence  in  avionics  systems 
firstly  leads  to  the  obsolescence  of  the  so  called 
prime  equipment.  This  means  the  equipment  of 
which  an  avionics  system  is  built.  Normally  the 
support  equipment  is  more  or  less  ignored  or  the 
analysis  is  postponed  to  a  later  date. 

This  situation  was  the  challenge  for  us  to  work  on  a 
“Consideration  of  Obsolescence  within  the  Design 
of  Modem  Avionics  Test  Systems”. 

We  analysed  today’s  situation  and  differentiated 
our  analysis  in  the  (COTS)  market,  customer 
requirements  and  technology. 

During  our  analysis  we  decided  to  not  only  analyse 
the  obsolescence  situation  within  the  test  systems 
design,  because  obsolescence  within  the  design  of 
modern  avionics  test  systems  is  only  one  of  the 
determining  factors.  All  factors  have  to  be  merged 
into  a  design  concept  inside  of  which  single  factors 
can’t  be  considered  stand  alone. 

Our  solution  -  covering  the  requirements  of  the  end 
user  of  our  systems  -  consists  of  a  design  concept 
covering  the  test  systems  critical  interfaces,  test 
system  standards  and  the  philosophy  of 
standardised  units. 

This  approach  ensures  the  flexibility  in  hardware 
and  software  to  adapt  quickly  as  needed  on  the 
commercial  market  and  to  guarantee  the  long  term 
support  as  needed  on  the  military  market. 


The  approach  is  adaptable  to  various  maintenance 
and  service  concepts  providing  each  customer 
(nation)  with  its  own  In-Service  concept  supporting 
mobile  and  fixed  service  stations. 

We  are  convinced  that  our  concept  ultimately 
benefits  to  our  customer  without  ignoring  the 
interests  of  industry. 


2.  List  of  Abbreviations  and  Acronyms 


Abbreviation 

Explanation 

A/C 

Aircraft 

AGE 

Aerospace  Ground  Equipment 

ATE 

Automatic  Test  Equipment 

COTS 

Commercial  Off  The  Shelf 

EADS 

European  Aeronautic,  Defence  and  Space 
Company 

GPATE 

General  Purpose  Automatic  Test  Equipment 

HW 

Hardware 

lETD 

Interactive  Electronic  Technical 
Documentation 

LRU 

Line  Replaceable  Unit 

RE 

Radio  Frequency 

STTE 

Special  to-Type  Test  Equipment 

SW 

Software 

TPS 

Test  Programme  Set 

3.  Introduction 

3.1.  History/Experience 

We,  of  the  Airborne  Systems  Division  of  EADS 
Deutschland  and  Test  and  Services  Division  of 
EADS  Erance,  have  a  long  lasting  experience  in  the 
design,  development  and  production  of  modem 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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avionics  test  systems.  During  the  last  ten  years  an 
additional  test  systems  line  -  the  Mobile  Test 
Systems  -  has  been  established  by  both  A.M. 
Divisions  of  EADS.  Together  we  cover  a  wide 
range  of  test  systems  and  applications. 

The  range  of  applications  of  Airborne  Systems  test 
systems  extends  from  development  test  systems 
over  production  test  systems  right  up  to  customer 
test  systems.  Various  test  applications  for  radar, 
electronic  warfare,  optical  and  general  avionics 
equipment  have  been  developed. 

The  range  of  applications  of  the  test  systems  of  Test 
and  Services  extends  from  development  test 
systems  over  production  test  systems  right  up  to 
customer  test  systems  as  well  for  the  civil  as  for  the 
military  markets.  More  than  3500  test  applications 
for  avionics  equipment  have  been  developed. 

Both  divisions  of  EADS  have  the  experience  with 
more  than  one  thousand  of  produced  test  systems, 
installed  world  wide  both  for  Aeronautic  and 
Defence  applications. 

3.2.  The  Problem 

Our  aim  of  looking  at  the  problems  of  obsolescence 
within  the  design  of  modem  avionics  test  systems 
involves  a  detailed  analysis  and  the  definition  of  a 
handy  solution  that  can  be  easily  applied  to  various 
test  systems. 

The  title  and  contents  of  this  article  differ  slightly 
from  the  others  which  dealt  mainly  with  the  so 
called  prime  equipment  of  the  defence  systems. 

When  dealing  mainly  with  obsolescence  problems 
within  the  design  of  prime  equipment,  there  is  a  big 
risk  that  the  associated  logistic  support  will  be 
neglected  or  left  out. 

Avionics  test  systems  belong  to  the  support 
equipment  -  Aerospace  Ground  Equipment  (AGE) 
-  that  keeps  the  prime  equipment  in  operation. 
Usually  the  main  attention  of  military  procurement 
organisations  is  drawn  to  the  prime  equipment.  To 
our  understanding  it  is  very  important,  that  the 
support  equipment  also  has  to  be  considered.  This 
equipment  has  to  support  the  military  systems 
during  their  whole  life  cycle.  This  means,  that  the 
life  time  period  is  normally  much  longer  than  the 
development  and  production  period  of  the  prime 
equipment. 

The  awareness  of  the  problems  of  obsolescence 
within  the  design  of  test  systems  comes  up  earlier 
than  for  prime  equipment.  Test  systems  normally 
are  not  flight  critical,  therefore  they  have  not  to 


fulfil  the  very  hard  qualification  requirements  of 
equipment  that  is  use  in  an  aircraft.  Eor  test  systems 
COTS  equipment  can  be  used. 

The  traditionally  long  procurement  periods  of 
military  equipment  sometimes  result  in 
obsolescence  problems  even  before  the  In-Service- 
Date  of  the  equipment.  The  Military  Customers,  as 
well  as  industry,  have  to  cope  with  new  challenges. 

During  the  last  decades,  test  systems  were  often 
designed  as  Special  to-Type  Test  Equipment 
(STTE)  for  a  dedicated  application,  for  a  particular 
prime  equipment. 

In  addition  to  the  STTE  solution,  several 
approaches  were  made  to  develop  universal  test 
systems  that  were  capable  of  supporting  multiple 
applications.  Unfortunately  this  traditional 
“Common  Core  Test  Concept”  sometimes  leads  to 
“overpowered”  core  systems  and  made  upgrade 
programmes  during  the  development  and  In-service 
phase  difficult  and  expensive. 

The  exceedingly  short  innovation  periods  of 
commercial  computers  and  measurement  devices 
have  forced  EADS  to  optimise  the  concept  for  the 
development  of  Test  Systems. 

We  analysed  the  situation  of  obsolescence  in  the 
design  of  modem  avionics  test  systems.  One 
important  conclusion  was,  that  we  not  only  have  to 
consider  the  obsolescence  of  the  hardware 
components  of  our  test  systems,  but  that  we  also 
have  to  consider  the  software. 

We  concentrated  our  analysis  on  developing  a 
conceptual  approach,  that  fits  in  with  the  complete 
life  cycle  of  our  test  systems. 

4.  Today’s  Situation  in  The  Design  of  Modern 
Avionics  Test  Systems 

4.1.  General 

Eirstly,  we  analysed  today’s  situation  in  the  design 
of  modem  avionics  test  systems.  We  divided  this 
analysis  up  into  three  different  categories: 

•  COTS  market 

•  customer  requirements 

•  technology 

All  the  above  three  elements  touch  the  different 
obsolescence  problems  we  have  to  cope  with. 

In  a  very  early  stage  of  our  analysis,  it  was  clear  to 
us  that  obsolescence  problems  must  be  considered 
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not  as  stand-alone  problems,  but  in  connection  with 
all  the  other  elements  involved.  A  stand-alone 
consideration  can  be  made  regarding  individual 
components;  e.g.  if  a  PC  board  has  to  be  developed 
and  one  or  more  components  become  obsolete.  This 
stand-alone  consideration,  however,  is  not 
meaningful  during  the  development  of  test  systems 
that  are  made  up  of  different  equipment. 

Therefore  we  developed  a  test  system  solution 
which  covers  nearly  all  aspects  of  the  problems 
within  the  design  of  modem  avionics  test  systems  - 
including  obsolescence  as  one  major  element. 

How  do  we  avoid,  or  better  -  mitigate  -,  the 
problems  resulting  out  of  obsolete  items? 

Before  answering  this  question,  let  us  look  a  little 
bit  closer  at  the  three  different  categories. 

4.2.  Today’s  Situation  -  COTS  Market  - 

The  COTS  (Commercial  Off  the  Shelf)  market, 
especially  for  computers  and  measurement/stimuli 
devices,  is  expanding  and  changing  faster  than  ever 
before. 

Obsolescence  and  non  availability  of  computer  HW 
and  SW,  as  well  as  obsolescence  of  measurement 
and  stimuli  devices,  become  a  day  to  day  problem. 

Standards  are  no  longer  being  defined  by  military 
requirements  (only).  Nowadays  they  are  mainly 
influenced  by  the  commercial  acceptance  of 
systems. 

Commercial  software  is  frequently  upgraded, 
sometimes  without  notifying  the  customers;  a 
downward  compatibility  is  not  always  guaranteed.  . 

4.3.  Today’s  Situation  -  Customer 
Requirements  - 

Ongoing  changes  in  a  nation’s  maintenance 
philosophy  result  in  extreme  flexibility  within  the 
necessary  test  system  development.  These  changes 
are  mainly  driven  by  reduced  budgets,  changing 
operational  requirements  and  adaptation  to 
international  /  multinational  programmes. 

Increasing  the  complexity  of  the  avionics  systems, 
combined  with  the  decreasing  availability  and 
capability  of  military  operators,  lead  to  a 
requirement  for  “Intelligent  Test  System 
Solutions”. 

The  service  periods  of  military  operators  is 
continuously  being  reduced,  as  is  the  quantity  of 
qualified  staff.  The  qualification  of  the  operators  is 


sometimes  not  sufficient  for  the  tasks  to  be  carried 
out.  Therefore  the  test  systems  have  to  compensate 
this  lack  of  qualification.  In  addition  to  the 
traditional  tasks  of  a  test  system,  the  power  of  the 
integrated  computer  systems  allow  an  increased 
spectrum  of  usability.  There  is  an  upcoming 
requirement  for  diagnostic  capability,  integrated 
training  features  and  lETD  (Interactive  Electronic 
Technical  Documentation). 

Prime  equipment  upgrade  programmes  require  - 
during  the  test  systems  life  cycle  -  an 
implementation  of  several  types/generations  of 
technologies  into  the  test  systems.  Eor  example: 
during  a  mid-term  upgrade  programme,  new 
electronic  equipment  is  integrated  into  an  old 
aircraft.  This  means,  you  have  to  manage  different 
configurations  of  avionics  equipment  in  parallel, 
that  will  have  to  be  maintained  by  the  test  systems 
for  a  long  time. 

4.4.  Today’s  Situation  -  Technology  - 

Decreasing  budgets  and  reduced  order  quantities 
force  developers  of  military  test  systems  to  design 
solutions  based  on  commercial  products  in  almost 
every  new  project  development  phase.  The 
consequence  is,  that  problems  are  appearing  with 
obsolete  items. 

Traditional  test  concepts,  such  as  large  universal 
test  systems,  may  lead  to  "overpowered"  core 
systems,  test  systems  being  designed  to  cover  all 
possible  test  requirements  for  the  respective 
equipment  or  system.  Ballast  caused  by 
commonality  make  upgrade  programmes  -  during 
the  product  life  cycle  -  difficult  and  expensive.  The 
necessary  flexibility  is  not  available.  Extreme  short 
innovation  cycles  of  avionics  systems  require  a 
high  flexibility  and  growth  potential  in  the  design 
of  test  systems. 

In  the  past,  avionics  prime  equipment  had 
innovation  cycles  of  ten  and  more  years.  Today 
these  innovation  cycles  are  much  shorter, 
sometimes  only  a  few  years. 

4.5.  Requirements  of  the  End  User 

Derived  out  of  today’s  situation  we  have  tried  to 
sum  up  the  requirements  and  concerns  of  the  end 
user  of  modern  avionics  test  systems.  This  list 
might  not  be  complete,  but  we  think  that  it  covers  at 
least  all  the  main  topics. 
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We  always  have  to  keep  in  mind,  that  the 

obsolescence  problems  can  not  be  considered 

stand-alone,  but  within  a  complete  picture. 

A  new  test  system  should: 

•  take  into  account  existing  test  systems  already 
in  use 

•  use  an  existing  development  &  production  SW 
where  possible 

•  start  with  a  low  cost  “Basic  Core  System” 

•  use  a  modular  design,  easy  to  maintain  and  to 
upgrade 

•  prevent  redundant  test-resources 

•  be  configurable  to  specific  purpose  /  national 
applications  /  country  specific  features 
(extendable  on  time  schedule  with  additional 
resources  and  applications) 

•  allow  TPS  (Test  Programme  Set)  programming 
to  be  independent  of  test-resources 

•  provide  user  friendly  man  machine  interfaces 

•  facilitate  TPS  programming  by  prime 
equipment  supplier 

•  allow  easy  interfacing  of  specific  test  devices 
needed  only  for  one  TPS 


All  these  requirements  and  concerns  should  be 
addressed  against  the  background  of  long  term  life 
cycle  management  over  a  period  of  20-40  years. 

You  should  know  the  customers  requirements 
before  you  start  to  design  and  develop  a  test 
system.  The  military  customer  is  looking  for  a  long 
term  serviceability  of  our  solutions,  but  also 
wanting  state-of-the-art  solutions. 

There  is  a  British  saying  that  describes  that 
situation  very  well.  We  have  “to  kill  two  birds  with 
one  stone”.  In  fact,  in  reality:  not  two.. .but  many 
birds  ... 

5.  Solutions 

5.1.  General 

Obsolescence  is  a  problem  which  is  with  us  to  stay. 
Developers  must  find  a  way  to  minimise  its  effect. 
But  it  has  to  be  clear,  that  the  obsolescence  problem 
has  to  be  considered  in  connection  with  all  the  other 
determining  factors. 


Determining  Factors  for  the  Test  System  Design 


strategy 


Illustration  1:  Determining  Factors  for  the  Test  System  Design 
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One  way  of  solving  a  large  majority  of  the 
obsolescence  problems  is  to 

•  analyse  the  critical  interfaces 

•  consider  the  available  standards 

•  use  standard  units 

i.e.  use  units  which  can,  without  alteration,  be  built 
into  numerous  test  systems. 

During  this  process  you  have  to  be  reasonable  and 
as  far  as  possible  you  have  to  foresee  upcoming 
problems. 

This  methods  not  only  reduces  development  costs, 
but  also  ensures  that  any  up-coming  obsolete  items 
are  dealt  with,  over  a  wide  range  of  equipment,  thus 
reducing  the  cost  of  the  problem. 

5.2.  Test  Systems  Critical  Interfaces 

Defining  and  using  Critical  Interfaces  between  the 
subsystems  and  components  of  an  ATE  is  a  key 
factor  for  “The  Philosophy  of  Standardised  Units”. 

The  choice  of  these  interfaces  defines  the  level  of 
modularity  and  flexibility  of  the  test  system  in 
terms  of: 

•  Capability  to  host  TPS  and  to  grow  in 
configuration  depending  on  the  units  to  be 
tested  with  the: 

-  Capability  to  install  easily  TPS  on  the  ATE, 

-  Capability  to  configure  the  ATE  to  support  a 
given  set  of  LRU’ s 

-  Capability  to  expand  to  support  more  LRU’s 

-  Capability  to  expand  or  change  to  support 
modified  LRU’s 

•  Capability  to  adapt  to  user’s  needs  with  the: 

-  Capability  to  modify  or  replace  the  Man 
Machine  Interface 

-  Capability  to  add,  modify  or  replace  tools 

such  as  documentation  viewer,  test  results, 
data  bases, . 


•  Capability  to  deal  with  obsolescence  of 
components  with  the: 

-  Capability  to  replace  the  test  control 
computer, 

-  Capability  to  replace  the  operating  system, 

-  Capability  to  add  new  ATE  system  buses, 

-  Capability  to  expand  the  switching  system, 

-  Capability  to  add  or  replace  test  resources, 

-  Capability  to  add  or  replace  software 
components  including  compiler  and  run  time 
system  used  for  TPS. 

The  illustration  2  below  shows  the  main  typical 
interfaces  needed  to  support  the  above 
requirements. 

These  test  system  critical  interfaces  are  a  challenge 
for  customers  and  suppliers.  They  not  only  need  to 
be  carefully  defined  but  also  to  be  implemented  by 
standard,  insuring  freedom  of  choice  for 
components  and  long  term  support.  This  topic  will 
be  discussed  in  the  next  paragraph  (5.3). 

There  are  other  key  factors  for  success  to  consider 
such  as  (and  not  limited  to): 

•  Avoid  the  change  of  critical  interfaces, 

•  Keep  requirements  on  a  very  high  level 

•  Built  systems  based  on  commercial  equipment 
(COTS) 

•  Buy  from  supplier  that  has  many  customers  to 
have  the  chance  of  amortising/splitting  the  cost 
of  obsolescence.  If  you  are  by  yourself  you 
have  to  pay  100%. 

•  Convince  suppliers  of  key  COTS  item  to  buffer 
changes  of  components  to  avoid  to  pay  charges 
for  obsolescence,  order  batches  not  single  items 

•  You  need  to  be  fast  in  the  development  of  your 
systems,  they  shouldn’t  be  obsolete  when  put 
on  the  market. 
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Test  Systems  Critical  Interfaces 


Software 


IVMI 

Compiler  ^ 

Executive 

OS  Interface 

OS 


Test  Resource  Drivers 


TPS  Software 


Illustration  2:  Test  Systems  Critical  Interfaces 

5.3.  Test  System  Standards 

The  critical  interfaces  discussed  above  should  be 
implemented  by  standard  ensuring: 

•  freedom  of  choice  for  components, 

•  long  term  support. 

The  technologies  available  today  in  the  area  of 
computers  and  instrumentation  allow  to  find  off- 
the-shelf  industrial  standards  to  match  most  of  the 
ATE  system  critical  interfaces. 

However,  these  standards  may  change  too  fast  to 
ensure  at  the  same  time  the  freedom  of  choice  for 
components  and  a  long  term  support  matching  the 
life  cycle  of  the  defence  systems. 

In  order  to  address  this  problem  we  recommend  to 
differentiate  between: 

•  Very  Critical  Interface  that  ensures  the 
portability  and  rehosting  of  TPS  and 
protects  most  of  the  investment  in  test 
applications, 

•  Critical  Interfaces  internal  to  the  ATE 
itself. 

The  Very  Critical  Interfaces  are  made  up  of  the 
TPS  programming  language  and  of  the  ATE 


Hardware 
Switching  System 


ATE  SYSTEM 


connection  system.  The  standard  in  these  area  shall 
be  stable  for  at  least  20  years  in  order  to  protect  the 
investment  made  in  developing  test  applications. 
Industrial  standard  may  not  be  up  to  the  task 
without  the  effort  of  aeronautic  and  defence 
customers  to  define,  use  and  enforce  such  standard. 

On  the  other  hand,  the  Critical  Interfaces  shall  be 
off-the-shelf  standard  widely  used  by  the  industry. 
Their  rate  of  change  should  be  of  at  least  5  years. 
The  customers  should  avoid  to  enforce  these 
standards  in  order  to  make  possible  the  best  choice 
of  components.  The  computer  and  software 
technologies  available  today  made  it  possible  to 
adapt  and  interface  between  the  different  standards 
at  a  reasonable  cost,  whenever  changes  cannot  be 
avoided. 

5.4.  Philosophy  of  Standardised  Units 

With  our  background  of  a  wide  spectrum  of 
different  applications  and  the  experience  of  many 
national  and  international  programmes,  EADS 
developed  the  “Philosophy  of  Standardised  Units”. 

The  idea  of  The  Philosophy  of  Standardised  Units 
is  not  new.  The  principle  uses  a  pool  of  existing 
standard  units  for  the  various  applications 
comprising  of: 
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•  Controller 

•  Commercial  Software 

•  Specific  Software 

•  Digital  Measurement  Equipment 


•  RE  Measurement  Equipment 

•  Power  Supplies  and 

•  Mountings. 


The  Philosophy  of  Standardised  Units  -  The  Solution  - 


Customised 
Test  System 


Project  specific  units 
i.e.  Hardware/Software  not 
existent  in  Standard  Units 


Future  Standard  Units 


Existing 
Standard  Units 


Commercial  SW 


Speciflc  SW 


UNIX  Embedded 

Ccntrciler  Controller 


Windows  NT  Itendheld 
Cortroller  Terminal 


Controller 


Shock 

Mounts 

Racks 

Botes 

Drawers 

Mountings 


AC 

230V 


AC 

3 X  115V 


Power  Supplies 


II  AX'er 


Switching 


Timing 

Analyser 


Digital  Equipment 


ESM  ECM 

Radar  IFF 

RF  Measurements 


Illustration  3:  The  Philosophy  of  Standardised  Units  -  The  Solution  - 


The  core  system,  and  all  the  elements  that  are 
suitable  for  reaching  the  development  goal,  are 
huilt  up  out  of  this  pool.  They  are  amended  hy 
project  specific  units,  i.e.  hardware/software  that  is 
not  yet  existent  in  the  pool  of  standard  units. 

In  the  next  step,  the  product  “New  Test  System”  is 
analysed  and  all  the  new  elements  that  are  suitable 
for  integration  into  the  standard  pool  are  identified 
and  added  to  it.  The  “old”  existing  elements  will  be 
upgraded  to  keep  the  pool  up-to-date. 

The  “Philosophy  of  Standardised  Units”  comprises 
the  following  technological  and  design 
requirements. 


Technology 

•  To  use  state-of-the-art  technology  in  test  and 
measurement  devices 

•  To  maximise  use  of  COTS  Equipment 

•  To  use  technology  with  long  term  availability 

•  To  prevent  obsolescence 
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Design 

•  To  define  a  test  system  design/architecture 
which  achieves  long  term  maintainability  (i.e. 
allowing  a  change  of  test  and  measurement 
devices  in  HW  and  SW  without  changing  the 
application) 

•  To  maximise  use  of  existing  Test  Programme 
Sets 

•  To  allow  growth  potential 

•  To  use  international  standards 

•  To  create  a  common  philosophy,  useahle  for 
various/multiple  maintenance  concepts  like 
shop,  flight-line,  modular,  fixed,  mobile,  etc. 

The  first  main  advantage  of  the  philosophy  of 
standardised  units  is  the  flexibility  in  hardware  and 
software,  having  the  capability  to  react  on  the 
commercial  market  by  being  independent  of  types 
of  equipment  and/or  manufacturers.  This 
philosophy  guarantees  the  long  term  support  for  the 
military  market  over  the  long  support  periods,  that 
are  required  by  the  military  customers. 

To  a  certain  extend  interchangeability  and  even 
backward  compatibility  of  the  used  test  systems 
units  can  be  accommodated.. 

The  second  main  advantage  is  that  it  is  adaptable  to 
various  maintenance  and  service  concepts. 

It  is  possible  to  provide  each  customer  and  each 
nation  with  its  own  In-Service  concept  without 
necessarily  inventing  a  new  test  system.  This  can  be 
achieved  by  using  mainly  the  available  pool.  The 
concept  also  supports  different  applications  of 
mobile  -  on  aircraft,  deployable  -  and  fixed  - 
development,  production,  shop  -  service  stations. 

Apart  from  the  two  cardinal  advantages,  it  is 
worthwhile  mentioning  advantages  like  reduction 
of  the  cost  for  operator  training  and  refresher 
courses  by  using  well  know  elements  and  standard 
man  machine  interfaces. 

The  Philosophy  of  Standardised  Units  represents  a 
design  concept  for  test  systems  which  allows 
flexibility  for  the  insertion  of  new  technology  in  the 
future  and  growth  within  the  test  systems. 

6.  Conclusion 

We  are  sure  that  we  are  at  the  beginning  of  a 
development  process  in  the  design  of  modem 
avionics  test  systems  that  forces  all  involved 
companies  to  redefine  their  concepts.  We  are 
however  also  convinced  that  our  concept  of 


standardised  units  can’t  be  implemented  in  a  very 
short  time. 

Obsolescence  in  the  design  of  modern  avionics  test 
systems  is  not  only  a  matter  of  component 
obsolescence;  measurement  and  stimuli  equipment 
have  to  be  considered  as  well  as  computer  HW  and 
SW. 

A  consideration  of  single  HW  or  SW  elements 
leads  to  a  collection  of  single  solutions.  These 
solutions  are  often  contradictory,  and  expensive. 

Our  solution  points  out  a  cost  optimised  way  of 
integrating  COTS  products  -  including  all  the  well 
known  obsolescence  problems  -  in  a 
philosophy/strategy  that  is  optimised  for  military 
requirements,  e.g.  long  term 

availability /supportability. 

The  possibility  of  a  continuous  engineering  process 
in  the  design  and  development  of  modem  avionics 
test  systems  -  taking  into  consideration  already 
existing  SW-  and  HW  elements  -  guarantees  a 
constant  market  presence  at  the  front-end  of  the 
technological  development. 

The  design  concept  is  an  evolutionary  approach 
based  on  the  existing  test  system  design  and  it 
ensures  maximum  re-use  of  the  current  design  to 
protect  the  investments  already  made. 

All  the  above  mentioned  activities  ultimately 
benefit  our  customers,  but  the  active  co-operation 
of  the  customer  is  required. 

Our  intention  was  to  combine  the  best  on  whatever 
level  necessary,  and,  if  we  may  be  so  bold  as  to 
mention  it,  we  think  that  we  have  achieved  just  that. 
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SUMMARY 

Commercial  off  the  shelf  (COTS)  products  are  being  used  increasingly  in  military  systems,  an  approach  that  offers 
many  advantages  including  lower  initial  acquisition  costs,  faster  delivery  to  the  front  line  and  ability  to  utilise  the  latest 
advances  in  technology  -  a  seemingly  perfect  match  to  the  "faster,  better,  cheaper"  ethos  of  modern  acquisition 
initiatives.  COTS  products  do,  however,  bring  their  own  problems,  including  rapid  obsolescence,  lack  of  product 
control  and  fixed  functionality  optimised  for  the  non-military  market.  In  addition  to  addressing  the  complex  technical 
issues  that  the  use  of  COTS  products  brings.  Defence  Ministries  and  Industry  will  have  to  adapt  their  management 
approach  and  practices  if  the  full  potential  of  using  commercial  technology  is  to  be  realised,  and  dangerous  pitfalls 
avoided. 

This  paper  discusses  some  of  the  management  issues  that  will  have  to  be  addressed  and  draws  a  number  of  lessons 
relating  to  the  avoidance  of  obsolescence  problems  during  the  in-service  life  of  a  system  or  platform. 


BACKGROUND 

The  use  of  commercial  off  the  shelf  (COTS)  components 
is  becoming  an  increasingly  important  aspect  of  the 
acquisition  of  military  systems,  particularly  in  the  areas 
of  information  technology  and  communications.  The  use 
of  COTS  components  should  offer  the  potential  to 
harness  the  rapid  technological  developments  underway 
in  the  commercial  world  and  to  capitalise  on  the  lower 
costs  delivered  by  mass-market  developments.  Over 
recent  years,  these  potential  advantages  have  led  to  a 
view  within  the  defence  authorities  and  in  industry  that 
the  use  of  COTS  was  going  to  solve  many  long  standing 
problems  in  military  systems,  and  would  allow  more 
capable  systems  to  be  delivered  more  quickly,  at  lower 
cost. 

This  initial  widespread  optimism  is  now  being  replaced 
by  a  realisation  that  while  the  use  of  COTS  delivers 
many  advantages,  it  also  brings  many  difficulties  and 
challenges  of  its  own.  These  include  more  rapid  product 
obsolescence,  lack  of  control  over  product  support  and 
difficulty  in  predicting  future  developments.  Many  of 
these  difficulties  become  most  critical  after  systems  have 
entered  service  and  the  obsolescence  of  their  components 
has  started  to  have  a  significant  effect  on  support  and 
development. 


If  these  problems  with  obsolescence  in  COTS-based 
systems  are  to  be  solved  and  the  attendant  risks 
contained,  then  changes  are  required  to  the  management 
of  their  acquisition  and  support.  Much  work  has  been 
directed  at  the  technical  and  design  issues  relating  to  the 
use  of  COTS  products.  This  paper,  however,  explores  a 
number  of  aspects  of  the  through  life  management  of 
COTS-based  systems,  including  initial  acquisition, 
requirements  management,  managing  upgrades,  spares 
support  and  costing. 

The  paper  focuses  on  information  technology  (IT) 
systems,  as  it  is  in  this  area  that  the  rapid  advances  in 
commercial  technology  produce  the  greatest 
obsolescence  problem.  It  is  hoped,  however,  that  the 
paper  includes  lessons  of  application  in  other  acquisition 
domains. 

This  paper  is  based  on  work  undertaken  by  the  author  for 
the  UK  Ministry  of  Defence  (MOD)  Defence 
Procurement  Agency  (DP A)  and  Defence  Evaluation  and 
Research  Agency  (DERA)  Sea  Systems  Sector  as  part  of 
a  series  of  studies  aimed  at  improving  the  COTS 
acquisition  guidance  available  to  UK  MOD  staff.  The 
support  of  all  those  who  contributed  to  these  studies  is 
acknowledged. 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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COTS  AND  COTS-BASED  SYSTEMS  OVERVIEW 
Terminology 

Before  embarking  on  a  discussion  of  COTS  it  is 
necessary  to  define  exactly  what  we  are  talking  about,  as 
common  terms  are  often  used  inconsistently  in  this  field. 
In  this  paper  "COTS"  refers  to  commercial  off  the  shelf 
items,  that  is  those  that  are  developed  for  use  in  the 
commercial  market,  available  from  a  catalogue  or  other 
description  and  delivered  fully  developed  and  ready  for 
use.  The  paper  does  not  specifically  address  other  off 
the  shelf  acquisitions,  such  as  the  use  of  military  systems 
bought  with  little  modification  (sometimes  termed 
Military  Off  The  Shelf,  or  MOTS)  or  the  use  of  products 
developed  by  government  (Government  Off  The  Shelf, 
or  GOTS).  However,  MOTS  and  GOTS  items  share  a 
number  of  characteristics  with  COTS,  and  this  article 
may  offer  a  number  of  insights  of  value  to  those  involved 
in  such  acquisitions. 

Basic  Characteristics  of  COTS  Products 

The  basic  characteristics  of  COTS  components  stem 
from  the  fact  that  they  are  developed  for  commercial, 
rather  than  military,  purposes  and  that  they  are  sold  in 
large  numbers  (sometimes  millions).  COTS  products 
have  been  designed  to  make  a  profit  for  the  vendor,  and 
not  for  the  convenience  of  the  (minority)  military 
customer.  Upgrades  and  changes  are  driven  by  predicted 
return  on  investment  and  not  by  some  altruistic  desire  to 
improve  or  extend  a  product.  The  military  user  generally 
represents  a  small  minority  of  the  customers  of  a  given 
COTS  product,  and  military  specific  features  are  unlikely 
to  appear  high  on  the  list  of  priorities  for  the  vendor. 

It  is  not  the  intention  of  this  paper  to  provide  a  detailed 
description  of  the  advantages  and  disadvantages  of  using 
COTS  products.  However,  the  following  section 
summarise  the  main  points,  to  put  the  management 
problem  in  context. 

Advantages:  The  advantages  of  using  COTS  products 
have  been  advertised  widely  (possibly  too  widely).  They 
include  the  following: 

•  Low  initial  cost,  with  development  costs  amortised 
over  many  buyers 

•  Availability  of  established  support  arrangement, 
including  development  tools,  vendor  support  and 
spare  part  support 

•  Reduced  acquisition  times  by  the  use  of  standard 
pre-developed  components 

•  Ability  to  capitalise  on  upgrades  in  technology 
developed  for  the  commercial  market 

•  Ability  to  adapt  to  meet  new  requirements 

•  Potential  for  enhanced  interoperability 

Disadvantages 

The  use  of  COTS  products  is  not  all  good  news.  In 
particular,  COTS  products  suffer  from 


•  Rapid  obsolescence,  with  support  and  spares 
lifetimes  driven  by  commercial  markets  beyond  the 
control  of  the  defence  sector 

•  Lack  of  product  control  with  changes  being  made  to 
meet  commercial  drivers 

•  Lack  of  Design  Detail  leading  to  difficulties  in 
modifications  and  in  safety  and  security 
certification. 

•  Mismatch  with  Military  Standards 

COTS-BASED  SYSTEMS  AND  COMPLEXITY 

The  complexity  of  developing  a  COTS  based  system  is 
often  underestimated.  It  is  important  to  recognise  that 
there  is  a  considerable  difference  between  buying  a 
complete  COTS  system,  sold  commercially  in  the  form 
or  configuration  that  the  military  will  use,  and 
developing  a  system  based  on  COTS  components 
(referred  to  as  "COTS-based  systems"  in  this  article). 
Lack  of  recognition  of  this  COTS  characteristic  has  been 
at  the  root  of  many  management  issues  in  the 
development  of  military  COTS  based  systems. 

There  has  been  an  impression  that  COTS-based  systems 
are  easy  to  build,  and  therefore  the  use  of  COTS  will 
automatically  reduce  design  complexity  and  hence  cost, 
timescales  and  risks.  This  feeling  has,  to  some  extent, 
been  generated  by  an  incorrect  extrapolation  from  the 
observed  characteristics  of  complete  COTS  system 
purchases.  When  a  complete  COTS  system  is  purchased, 
the  system  design  has  been  carried  out  by  the  vendor  and 
its  complexity  is  hidden  from  the  purchaser.  Design  cost 
has  been  amortised  over  a  large  number  of  purchasers, 
reinforcing  the  impression  that  the  cost  of  COTS-based 
system  design  is  low. 

Unfortunately,  this  assumption  is  not  valid  for  a  typical 
military  COTS-based  systems,  which  will  contain  a  large 
number  of  COTS  components  or  products,  each  of  which 
is  purchased  separately  from  the  vendor  and  then 
integrated  to  form  a  new  system  configuration,  never 
previously  developed  and  unique  to  this  application. 
This  integration  will  involve  the  configuration  of 
individual  products  to  match  their  environment  and 
typically  require  the  development  of  custom  code  to 
provide  interfacing  functionality  and  to  meet  the  specific 
system  requirements. 

The  unique  configuration  will  also  place  the  individual 
components  in  a  new  environment,  never  tried  before, 
and  this  may  well  expose  incompatibilities  previously 
unknown  to  either  the  developers  or  the  COTS  vendors. 
The  situation  is  further  complicated  in  most  military 
systems  by  the  need  for  bespoke  applications  to  meet 
specific  military  requirements  and  the  need  to 
incorporate  bespoke  legacy  applications. 

As  a  consequence  of  these  issues,  COTS-based  systems 
require  at  least  as  much  effort  in  system  design  as  any 
system  based  on  bespoke  components.  Indeed,  it  may  be 
argued  that  the  fixed  functionality  and  performance  of 
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the  COTS  components  place  greater  constraints  on  the 
design  of  the  system,  forcing  more  iteration  between 
system  levels.  This  design  iteration  will  not  cease  when 
the  initial  design  is  completed. 

In  summary,  the  combination  of  a  unique  design,  the  use 
of  a  large  number  of  inflexible  components  in  a  new 
environment  and  a  mix  of  bespoke  and  COTS  elements, 
means  that,  contrary  to  widely  held  opinion,  large 
COTS-based  systems  are  inherently  complex. 
Management  plans  that  fail  to  recognise  this  complexity 
are  likely  to  underestimate  the  effort  and  time  required 
for  system  design,  both  during  initial  acquisition  and 
during  the  in  service  life  of  a  system. 

CONTINUOUS  DESIGN  PROCESS 

As  the  underlying  COTS  components  are  replaced  by 
others  (as  they  surely  will  be),  the  system  configuration 
or  design  needs  revisiting  to  address  the  characteristics 
and  functionality  of  the  new  components.  In  some  cases 
the  changes  will  be  minor,  for  instance  when  a 
component  is  superseded  by  another  without  affecting  its 
functionality  or  interfacing,  and  the  effort  required  will 
principally  be  focussed  on  configuration  management. 
In  other  cases,  however,  the  withdrawal  of  support  for  a 
key  infrastructure  component  (such  as  an  operating 
system  or  database)  may  necessitate  a  major  redesign 
with  impact  on  many  other  components  in  the  system. 

The  interrelated  nature  of  IT  products  can  lead  to  a 
domino  effect,  with  the  change  of  one  component 
requiring  the  replacement  of  many  others.  For  example 
the  change  to  a  new  processor  could  require  a  new 
operating  system,  which  may  in  turn  require  application 
programmes  to  be  replaced.  It  may  also  require  the 
redesign  of  bespoke  application  software  developed  for 
the  system.  The  unique  nature  of  a  given  military  system 
also  means  that  with  each  change,  components  may  be 
placed  in  a  new  environment,  which  can  expose 
shortcomings  in  products  not  previously  uncovered. 
This  will  need  to  be  resolved  before  the  system  is  put 
into  service.  Each  major  increment  will,  of  course,  also 
bring  the  need  for  extensive  testing  and  revalidation. 

The  rapid  turnover  of  COTS  products  and  the 
consequent  changes  to  the  system  design  and 
configuration  means  that  a  COTS-based  system  is  in  a 
state  of  continuous  design,  throughout  its  lifetime.  (See 
Figure  1) 

This  fact  needs  to  be  recognised  in  the  through  life 
management  of  a  COTS-based  system,  and  suitable 
resources  and  funding  to  support  the  continuous  design 
process  must  be  secured. 

MAGNITUDE  OF  TECHNOUOGY  CHANGES 

It  is  readily  apparent  that  the  technology  on  which  COTS 
products  are  based  will  change  during  the  lifetime  of  a 
typical  military  system.  While  it  is  universally 


recognised  that  that  changes  will  take  place  in 
technology,  discussions  with  a  wide  range  of  military 
projects  suggests  that  the  magnitude  of  the  changes  is 
often  not  appreciated  or  taken  into  account  in  project 
management  planning. 

To  get  some  idea  of  the  likely  impact  of  technology 
changes  on  military  systems  we  need  to  look  forward 
some  twenty  five  years  (at  the  end  of  which  many 
systems  currently  in  the  concept  stage  will  still  be  in 
service).  If  we  look  back  twenty-five  years,  to  1975,  we 
can  see  how  far  commercial  information  technology  has 
moved.  In  1975,  there  were  no  desktop  computers,  no 
Internet  (in  the  form  we  would  recognise  today)  and  no 
mobile  phones.  Object  oriented  programming  was  an 
obscure  specialist  technique  and  interfaces  were  (at  best) 
text  based.  The  microprocessor  was  in  its  infancy  (the  6 
MHz  8080  and  6.4  MHz  6800  were  both  launched  in 
1974).  Windowed  user  interfaces,  mice,  LCD  screens, 
the  world  wide  web,  TCP/IP  and  HTML  were  still  all 
years  in  the  future.  Figure  2  shows  some  of  the  key 
events  over  the  last  twenty-five  years.  In  short,  we  can 
see  that  commercial  technology  has  changed  beyond  all 
recognition. 

It  is  generally  considered  that  the  rate  of  change  of 
technology  has  been  increasing  over  this  period,  and 
today  new  concepts  and  ideas  are  being  introduced  at  a 
high  rate.  (The  life  of  a  commercial  software  product  is 
typically  12-18  months  before  it  is  replaced  by  a  new 
version,  and  some  2-3  years  before  all  support  is 
dropped.)  It  is  against  this  background  that  we  are 
asking  industry  to  develop  systems  that  will  last  for 
twenty  or  more  years  beyond  In  Service  Date  (ISD). 

Some  changes  during  this  time  will  be  predictable.  The 
cost  of  processing  power  will  continue  to  fall,  bandwidth 
available  to  commercial  users  will  expand,  and  the  cost 
of  storage  (volatile  and  non-volatile)  will  reduce. 
However,  as  the  last  ten  or  twenty  years  has  shown  us, 
the  way  in  which  these  developments  will  be  exploited  in 
the  commercial  world  is  impossible  to  predict. 

If  specific  technology  trends  can't  be  predicted,  those 
considering  the  design  and  implementation  of  COTS- 
based  systems  must  consider  the  magnitude  of  the 
changes  that  are  likely  to  take  place.  In  the  next  15  years 
we  will  see  changes  as  far  reaching  as:  the  removal  of 
keyboards  and  screens  as  interface  devices,  the  demise  of 
a  web  based  approach  or  indeed  of  the  internet  as  we 
know  it,  the  advent  of  effectively  unlimited  bandwidth 
for  commercial  users  (with  the  subsequent 
transformation  in  commercial  system  architectures  and 
techniques)  or  the  demise  of  the  concept  of  a  workstation 
running  software.  It  is  not  suggested  that  all  (or  any)  of 
these  specific  possibilities  will  definitely  occur,  but 
changes  of  this  magnitude  are  certain  to  arise.  The 
challenge  to  military  COTS-based  systems  designers  is 
to  develop  architectures  and  design  and  management 
approaches  that  can  deal  with  this  level  of  innovation 
during  the  25-year  life  of  a  typical  military  project. 
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The  rate  of  change  of  technology  means  that  a  system 
will  have  to  deal  with  more  than  just  component 
obsolescence  during  its  lifetime.  In  the  typical  25-year 
life  of  a  system,  commercial  technology  may  be  expected 
to  have  changed  beyond  recognition.  Current  standards, 
design  approaches  and  architectures  will  have  been 
superseded  and  forgotten.  There  is  very  little  scope  for 
assuming  that  we  could  continue  to  use  today's  hardware 
and  software  solutions  throughout  the  life  of  a  military 
COTS  based  system.  Even  though  we  do  not  know 
exactly  what  the  changes  will  be,  we  must  plan  to 
manage  this  level  of  technology  change  if  fatal 
obsolescence  problems  are  to  be  avoided. 

REQUIREMENTS  MANAGEMENT 

All  studies  into  the  use  of  COTS  in  military  systems 

emphasise  the  need  for  a  suitable  process  to  manage 

requirements  and  requirement  trade-offs.  It  is 

considered,  however,  that  we  have  yet  to  see  a  system  or 

management  approach  that  handles  this  task 

satisfactorily. 

If  a  COTS  product  is  to  be  used  in  a  system,  there  is  very 
little  scope  to  change  its  functionality  (although  many 
products  have  parameters  and  settings  that  can  be 
changed).  When  a  COTS  product  is  selected,  it  is  highly 
unlikely  that  its  characteristics  will  match  precisely  those 
of  the  requirement.  This  implies  that  it  may  be  sensible 
to  accept  the  capability  offered  by  the  product  despite  the 
fact  that  it  is  not  precisely  what  was  originally  demanded 
by  the  user. 

As  the  design  becomes  more  detailed,  and  different 
combinations  of  products  are  selected,  then  the  match  of 
these  to  the  original  specification  will  need  to  be 
assessed.  In  some  cases  the  advantages  (low  price, 
availability,  good  support)  offered  by  a  COTS  product 
will  outweigh  the  fact  that  it  does  not  match  the  original 
requirement.  In  other  cases,  there  may  be  a  need  to 
select  a  different  product,  or  use  the  product  and  enhance 
its  capability  by  the  use  of  other  products,  or  by 
producing  some  bespoke  application  code  to  provide  the 
required  functionality.  In  many  cases,  of  course,  a 
COTS  product  will  have  features  that  were  not  originally 
included  in  the  requirement,  but  which  are  of  value  to  the 
customer.  Design  decisions  such  as  these  can  only  be 
carried  out  if  the  design  team  has  the  skills  and 
experience  to  understand  the  needs  of  the  user,  and  the 
impact  of  any  possible  design  changes.  This  will  require 
a  very  close  relationship  between  the  designer/system 
integrator  and  the  user  community. 

Trade-offs  between  cost,  risk,  availability  and 
functionality  will  continue  throughout  the  life  of  the 
system.  As  obsolescence  forces  the  change  to  a 
component,  the  selection  of  its  replacement  will  require 
the  same  assessments  to  be  carried  out,  possibly  leading 
to  further  agreed  changes  to  the  user's 


expectations/requirement.  The  timescales  of  changes 
will  often  mean  that  later  fielded  systems  are  different 
from  their  predecessors,  leading  to  the  potential  for  a 
range  of  different  systems  in  service,  each  developed 
during  trade-offs  for  particular  systems  or  batches  of 
systems. 

An  additional  feature  of  COTS-based  systems  is  that  the 
use  of  commercial  technology  should  allow  the  rapid 
exploitation  of  advances  in  the  commercial  world.  This, 
in  turn,  means  that  COTS-based  systems  offer  the  chance 
to  enhance  the  requirement  in  a  cost-effective  manner. 
In  particular  it  should  allow  military  systems  to  exploit 
new  applications  and  methods  of  working  in  the 
commercial  world.  The  management  of  upgrades  will 
need  careful  control;  this  is  discussed  further  below. 

The  aspects  discussed  above  indicate  that  if  the  full 
potential  of  COTS-based  systems  are  to  be  exploited, 
then  a  close  and  dynamic  relationship  is  required 
between  end  users,  procurement  staff  and  industry.  This 
close  working  relationship  will  be  required  throughout 
the  life  of  the  system,  as  trade-offs  and  requirement 
developments  are  initiated  by  COTS  product  changes 
forced  by  obsolescence  and  upgrades.  Such 

relationships  are  rare,  with  traditional  acquisition 
approaches  often  leading  to  a  confrontational 
relationship,  rather  than  close  cooperation. 

A  key  to  making  sound  decisions  in  this  dynamic 
environment  will  be  a  clear  understanding  by  all  parties 
of  the  way  in  which  commercial  technology  is 
advancing.  Such  knowledge  will  permit  a  realistic  vision 
of  what  is  likely  to  become  feasible  in  the  near  future 
and  will  assist  in  foreseeing  and  managing  potential 
obsolescence  problems. 

In  summary,  COTS-based  systems  involve  considerable 
effort  to  be  placed  on  requirement  negotiation  and  trade¬ 
off.  This  process  needs  to  involve  all  stakeholders,  and 
many  of  the  detailed  decisions  will  continue  to  be 
required  beyond  Main  Gate.  Requirements  evolution  will 
continue  throughout  the  life  of  the  system,  as  new 
products  are  delivered  by  developments  in  technology 
and  old  products  become  unsupportable. 

The  use  of  rapidly  developing  commercial  components 
brings  the  need  for  a  paradigm  shift  in  requirements 
management.  Conventional  tools  and  methods  are 
inadequate  to  either  capitalise  on  the  huge  advantages 
that  COTS  products  could  deliver  or  to  avoid  the  pitfalls 
of  obsolescence.  A  much  greater  emphasis  is  required 
on  involving  all  stakeholders  and  a  new  approach  to 
requirements  management  is  required,  based  on 
continuous  requirements  evolution.  If  the  full  potential  of 
COTS-based  systems  is  to  be  exploited,  then  a  close  and 
dynamic  relationship  is  required  between  users, 
procurement  authorities  and  industry. 
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COST  FORECASTING  AND  FINANCIAL 
MANAGEMENT 

Successful  project  management  includes  a  need  to 
predict  future  costs,  and  plan  future  spending  and 
manage  the  programme  to  remain  within  allocated 
budgets.  In  the  procurement  of  military  systems,  it  has 
long  been  recognised  that  initial  acquisition  costs  are 
heavily  outweighed  by  the  costs  of  in  service  support, 
and  this  has  recently  led  to  an  emphasis  on  through  life 
or  whole  life  costs. 

Unfortunately,  however,  accurate  prediction  of  the  long¬ 
term  costs  of  a  complex  COTS-based  system  is  not 
possible,  for  a  number  of  reasons.  These  include: 

•  A  lack  of  suitable  cost  models. 

•  No  agreed  MOD/industry  process  for  the 
maintenance  and  development  of  COTS-based 
systems  through  life,  making  assessment  of  through 
life  costs  infeasible. 

•  Volatility  and  unpredictability  of  future 
developments  in  technology. 

•  Unpredictability  of  the  direction  of  future 
commercial  developments  and  their  applicability  to 
military  systems. 

This  poses  particular  problems  in  military  system 
acquisition,  in  which  acquisition  authorities  are  expected 
to  provide  reliable  through  life  cost  estimates  early  in  the 
programme  to  support  the  choice  of  contractor  or 
solution.  There  may  be  reasonable  assessments  of  costs 
through  the  initial  acquisition  of  the  system  but  cost 
estimates  beyond  this  will  be  subject  to  significant 
uncertainty. 

It  is  not  possible  to  accurately  predict  the  through  life 
cost  of  a  COTS  based  system.  This  fact  needs  to  be 
recognised  in  the  planning  and  funding  of  systems,  and 
runs  counter  to  most  standard  defence  acquisition 
strategies.  Failure  to  plan  for  this  uncertainty,  and  to 
secure  adequate  flexibility  in  funding  will  delay  the 
introduction  of  updates,  leading  to  increased  problems 
with  obsolescence  and  support. 

SAEETY  AND  SECURITY  MANAGEMENT 

The  use  of  COTS  products  in  systems  introduces  some 
significant  difficulties  with  regard  to  system  integrity 
assessments,  in  particular  for  safety  and  security 
assessment  and  accreditation.  Those  problems  are 
caused  by  a  number  of  factors,  including  the  way  that 
COTS  products  are  developed  and  controlled,  the  lack  of 
information  and  the  rapid  obsolescence  and  replacement 
of  products. 

The  military  world  has  traditionally  insisted  on  systems 
meeting  specific  standards  regarding  product  safety.  It 
can  generally  be  assumed  that  COTS  products  will  not 
have  been  designed  to  meet  these  specific  standards  , 
although  in  some  cases  equivalent  civil  standards  will 
have  been  addressed.  In  some  cases  these  standards  will 
be  acceptable  for  use  in  the  military  environment,  and 


the  explicit  requirement  to  meet  a  military  standard  can 
be  waived.  If  this  is  not  the  case,  however,  the  military 
system  procurer  may  have  to  gather  further  evidence  or 
undertake  specific  tests  on  the  proposed  or  delivered 
products  to  assess  their  safety.  Such  tests  may  not, 
however,  be  cheap  and  gaining  assurance  that  they  will 
remain  valid  for  all  deliveries  may  be  difficult.  For 
example  the  source  and  chemical  make-up  of  cases  and 
components  may  change  between  batches,  and  toxicity 
tests  undertaken  on  a  sample  product  may  not  be 
representative  of  all  such  products.  If  assurances  are 
required  that  tests  will  remain  valid,  then  a  manufacturer 
may  have  to  establish  additional  procedures  or  a  different 
product  line,  in  each  case  this  will  invite  additional  costs. 

COTS  software  presents  particular  difficulty  in  safety 
related  (or  safety  critical)  systems,  because  lack  of 
control  over  the  development  method  and  lack  of 
information  render  standard  methods  of  assessing 
software  quality  infeasible.  In  particular: 

•  COTS  products  have  already  been  designed,  and  so 
design  and  coding  methods  (such  as  the  use  of 
formal  methods)  can  not  be  influenced. 

•  Code  listings  are  not  generally  available  for  COTS 
software  products,  rendering  static  code  analysis 
impossible. 

•  COTS  products  will  generally  have  been  designed  to 
less  rigid  standards  than  those  demanded  by,  for 
instance,  Def  Stan  00-55. 

•  Large  software  infrastructure  components  (such  as 
operating  systems)  are  of  a  complexity  that  renders 
exhaustive  testing  impossible. 

Even  if  a  product  had  been  analysed  and  accepted,  the 
short  lifetime  of  COTS  products  can  force  repeated 
analysis.  Any  analysis  will  take  time,  and  this  may 
introduce  delays  in  re-confirming  the  safety  or  security 
accreditation  of  the  system. 

These  difficulties  can  be  mitigated  by  good  system 
design  (for  instance  by  partitioning  of  safety  critical 
elements  of  a  system,  or  by  adding  additional  safety 
controls),  and  by  using  alternative  assessment  methods 
(for  example  assessing  the  general  quality  of  a 
company's  software  or  gathering  evidence  on  the 
reliability  of  the  COTS  software  product).  The  selection 
of  the  supplier  should  include  an  analysis  of  his 
credentials  and  qualifications  in  supplying  safety  critical 
software.  The  assessment  of  the  system  and  the 
accreditation  task  itself  will  be  simpler  if  the  supplier  has 
a  suitable  track  record  and  is  familiar  with  the 
development  and  accreditation  of  safety  critical  items. 

The  safety  and  security  accreditation  of  COTS  based 
systems  presents  considerable  technical,  design  and 
management  challenges.  The  difficulties  and  cost  of 
initial  and  ongoing  system  accreditation  must  be 
considered  in  the  development  of  COTS-based  systems 
and  in  the  selection  of  system  contractors.  Delays  in  the 
introduction  of  upgrades  caused  by  safety  and  security 
issues  will  increase  obsolescence  problems. 


26-6 


MANAGEMENT  OF  SYSTEM  UPGRADES 

The  key  to  successful  ongoing  support  and  improvement 
of  a  COTS-based  system  will  be  the  development  of  a 
suitable  infrastructure,  into  which  new  components  and 
products  can  be  inserted,  combined  with  the 
development  of  a  suitable  management  regime.  The 
implementation  of  an  open,  flexible  infrastructure, 
capable  of  adaptation,  extension  and  scaling  to  counter 
obsolescence  and  to  provide  new  functionality  and 
capacity,  is  not  a  simple  task.  Those  financing  and 
approving  programmes  will  have  to  take  into  account 
that  it  is  more  expensive  to  develop,  implement  and 
maintain  such  an  infrastructure  than  to  develop  one  that 
will  simply  meet  the  current  demands. 

Management  of  upgrades 

The  terminology  relating  to  system  modifications  and 
upgrades  is  complex,  diverse  and  inconsistent.  It  is 
important  to  distinguish  between  at  least  two  different 
categories  of  system  modification.  These  are: 

•  Changes  driven  by  obsolescence  ("technology 
refresh") 

•  Changes  to  increase  capability  ("capability 
upgrades") 

Having  made  that  distinction,  however,  we  must 
recognise  that  there  are  limited  opportunities  for 
upgrades,  and  the  need  for  cost  effectiveness  means  that 
any  significant  system  upgrade  event  will  include 
elements  from  both  of  these  categories.  As  the  different 
categories  of  modification  carry  different  responsibilities 
for  specification  and  funding,  this  has  the  potential  to 
introduce  management  difficulties. 

The  management  of  upgrades  in  a  COTS-based  system  is 
a  far  from  simple  problem.  It  involves  a  wide  range  of 
stakeholders  with  conflicting  interests,  and  successful 
resolution  will  require  understanding  of  many 
viewpoints  and  interests.  There  are  many  tightly 
interrelated  factors  to  be  considered  in  managing  system 
development  and  in  planning  individual  upgrade  events. 
These  include  cost,  time  required  to  implement  the 
upgrade,  time  required  for  preparation,  risk, 
obsolescence  pressures,  availability  of  COTS  and  legacy 
components,  platform  programmes,  links  with  other 
programmes  and  specific  operational  demands.  (Figure 
3).  These  various  aspects  will  need  to  be  assessed  and 
traded  off  in  any  particular  upgrade,  and  this  will  require 
input  and  understanding  by  all  stakeholders.  The 
complex  interrelationship  between  the  various 
stakeholders  will  be  simplified  by  clear  understanding  of 
their  individual  aims  and  responsibilities.  Managing  the 
upgrade  process  will  require  the  co-operation  and 
support  of  all  stakeholders. 

A  through  life  view  needs  to  be  taken  by  all  parties,  and 
each  must  have  an  incentive  to  act  in  a  manner  consistent 
with  getting  overall  value  for  money  on  a  through  life 
basis.  Amongst  other  things,  this  means  that: 


•  Those  controlling  the  finance  must  recognise  that 

there  will  often  be  an  up-front  cost  to  keep  a  system 
flexible  enough  to  accommodate  future  (but 

currently  unknown)  capability  upgrades. 

•  The  acquisition  authority  must  recognise  that 

industry  needs  to  make  a  profit,  and  enter  into 

arrangements  that  allow  for  this  while  still  ensuring 
good  value  for  money. 

•  Industry  must  be  given  the  incentive  to  invest  in 
system  upgrades  and  support  facilities  confident  in 
the  belief  that  these  will  contribute  to  increased 
return  at  a  later  date. 

•  The  long  term  strategy  for  maintaining  and 

upgrading  the  system  needs  to  be  agreed  early  in  the 
programme,  in  order  that  the  through  life  costs  can 
be  realistically  estimated  and  suitable  support 
arrangements  put  in  place. 

Management  plans  must  recognise  the  complexities  of 
managing  technology  refresh  and  capability  upgrades. 
Successful  management  of  upgrades  will  require  the 
cooperation  of  many  stakeholders,  often  with  different 
and  conflicting  priorities.  Successful  management  of 
upgrades  will  only  be  possible  if  there  is  a  close  and 
trusted  working  relationship  between  MOD  and  industry. 
The  confrontational  approach  that  is  typical  of  many 
current  procurements  will  preclude  cost  effective 
management. 

CONTRACTOR  LOGISTIC  SUPPORT 

Contractor  Logistic  Support  (CLS)  contracts,  where  the 
contractor  is  given  the  responsibility  for  supporting  a 
system  for  a  given  period,  are  often  seen  as  a  standard 
solution  for  reducing  risk  on  acquisition  authorities  and 
gaining  cost  effective  support  for  a  system.  However, 
for  COTS-based  systems,  there  is  a  danger  that,  unless 
supported  by  other  incentive  schemes,  the  traditional 
CLS  contract  can  contribute  to  increased  obsolescence 
and  higher  through  life  costs. 

As  has  been  pointed  out,  COTS-based  systems  suffer 
from  rapid  obsolescence,  leading  to  the  need  for 
continuous  technology  refresh  if  they  are  to  remain 
supportable.  If  a  contractor  accepts  a  firm  price  CLS 
contract  for,  say,  the  five  years  following  ISD  then  he 
will  be  under  an  obligation  to  support  the  system,  and 
hence  it  will  be  in  his  interests  to  keep  the  system  free 
from  obsolescence  problems  during  this  period. 
However,  he  will  not  wish  to  spend  more  money  than  is 
necessary  to  meet  his  contractual  commitments.  As  the 
end  of  the  CLS  period  approaches,  the  system  will  be  in 
a  state  that  no  further  technology  refresh  is  required  to 
maintain  the  system  for  the  remainder  of  the  period. 
This  point  will  probably  be  some  three  years  before  the 
end  of  the  period.  The  contractor  might  not,  therefore, 
undertake  any  work  to  mitigate  against  future 
obsolescence  during  these  three  years.  The  result  will  be 
that  at  the  end  of  the  CLS  period,  the  system  will  be 
about  to  become  unsupportable. 
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To  avoid  this,  there  is  a  need  to  provide  the  contractor 
with  the  incentive  to  keep  the  through  life  cost  of 
obsolescence  low.  A  fixed  CLS  period,  with  no  further 
obligation  or  commitment,  will  only  provide  an  incentive 
to  keep  the  obsolescence  cost  low  during  the  contracted 
period.  It  is  clear  that  we  will  have  to  look  at  innovative 
solutions  to  this  problems.  These  will  involve  working 
closely  with  their  suppliers  to  achieve  solutions  that  are 
of  mutual  benefit.  For  these  solutions  to  be  successful 
through  life,  the  benefits  will  have  to  be  capable  of  being 
shared  between  government  and  industry. 

The  management  of  CLS  for  a  COTS-based  system 
requires  careful  consideration,  as  the  conventional 
"hands  ojf'  approach  brings  particular  problems.  A 
closer  working  relationship,  and  cost  and  risk  sharing, 
will  be  required  if  a  successful  support  regime  is  to  be 
maintained. 


SPARES  SUPPORT  AND  CONFIGURATION 
CONTROU 

The  use  of  COTS  components  in  a  complex  system 
introduces  some  significant  difficulties  in  the  domain  of 
configuration  management  and  spares  support.  These 
challenges  are  a  direct  result  of  the  fundamental 
characteristics  of  COTS  products,  including; 

•  short  periods  of  commercial  availability, 

•  interdependence  between  products  (including 
hardware  and  software  interdependencies) 

•  the  potential  supply  of  compatible  COTS 
components  from  a  number  of  suppliers. 

The  principles  of  configuration  management  are  as  (or 
more)  important  in  COTS-based  systems  as  they  are  in 
traditional  systems.  However  the  widespread  use  of 
COTS  products  introduces  a  number  of  additional 
complexities  to  configuration  management.  These 
include; 

•  frequent  design  changes, 

•  lack  of  configuration  information  for  COTS 
products, 

•  inter-dependence  between  hardware  and  software, 

•  need  to  track  the  installation  of  new  versions  even 
when  they  appear  to  be  completely  interchangeable, 

•  the  many  minor  changes  made  to  new  COTS 
software  products, 

•  the  lack  of  reliability  data. 

The  short  supply  lifetime  of  COTS  components  and  the 
diversity  of  configurations  make  the  supply  of  hardware 
spares  difficult  to  manage.  As  new  products  appear,  and 
old  versions  are  no  longer  available,  there  will  be  a 
requirement  to  certify  new  products  for  use  in  a  system 
and  manage  their  supply  and  availability  for  the  different 
system  configurations  in  use. 

The  use  of  COTS  components  brings  the  potential  for  a 
configuration  explosion,  with  each  installation  (and  each 
sub-system  within  the  installation)  being  significantly 


different  from  others.  This  in  turn  brings  complexities 
for  spares  and  support  management.  A  balance  will  have 
to  be  struck  between  containing  this  diversity  and  the 
cost  of  limiting  implementations  to  a  manageable  subset 
of  configurations. 

Whole  life  buys  (or  "Through  life  buys"  or  "Lifetime 
buys")  are  often  proposed  as  a  strategy  for  dealing  with 
hardware  obsolescence.  Unfortunately,  experience  has 
shown  that  these  are  rarely  a  realistic  solution,  for  a 
number  of  reasons; 

•  Inter-relationships  between  software  and  hardware  - 

COTS-based  systems  often  exhibit  a  strong 
interdependence  between  their  components,  and 
particularly  between  the  software  (both 

infrastructure  and  application)  and  the  hardware  on 
which  it  runs.  In  the  commercial  world,  new 
processor  upgrades  are  commonplace,  and  as  new 
software  is  developed,  support  for  older  hardware  is 
often  dropped.  The  consequence  of  this  is  that  if 
hardware  is  not  upgraded  then  in  a  relatively  short 
timescale,  software  cannot  be  upgraded  further  with 
a  direct  effect  on  the  capability  of  the  system  to 
react  to  new  threats  and  requirements. 

•  Loss  of  ability  to  exploit  new  technology  -  If  the 
infrastructure  hardware  and  software  becomes 
frozen,  then  the  capacity  to  modify  the  system  to 
add  new  functionality  is  reduced.  Software 
packages  that  the  users  may  like  incorporated  into 
the  system  will  not  be  available,  because  a  modem 
commercial  package  will  expect  and  require  up  to 
date  or  recent  versions  of  the  operating  system, 
processors,  peripherals  etc. 

•  Need  for  system  development  support  environment  - 
In  the  longer  term  the  decision  to  limit  the  system  to 
obsolete  technology  will  affect  the  development 
environment  as  well  as  the  system  itself.  For 
example,  as  new  software  languages  are  developed, 
compilers  will  only  be  written  for  newer  processors 
and  operating  systems.  This  will  further  limit  the 
ability  to  upgrade  the  system. 

•  Difficulty  in  predicting  numbers  -  It  is  difficult  to 
gather  or  obtain  MTBF  figures  for  COTS  products, 
either  because  the  data  has  not  been  gathered,  or 
because  they  have  relatively  short  life  histories,  or 
because  they  have  not  been  used  in  representative 
environments.  This  lack  of  data,  combined  with  the 
possibility  of  the  spares  being  rendered  unsuitable 
by  other  changes  in  the  system,  represents  a  major 
risk  in  costing  and  undertaking  whole  life  buys  of 
spares. 

Spares  support  for  COTS-based  system  presents  a 
complex  management  challenge,  with  the  potential  for 
serious  configuration  management  problems.  The 
principles  of  configuration  management  are  just  as 
important  for  a  COTS-based  system  as  for  any  other 
procurement,  but  the  use  of  COTS  products  brings  the 
potential  for  an  explosion  in  system  and  subsystem 
configurations.  This  diversity  carries  a  cost  overhead. 
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and  will  need  to  be  contained.  It  is  essential  that  this 
issues  is  addressed  in  other  management  areas, 
including  technical  design,  funding  and  support 


management.  The  use  of  through  life  buys  of  spares  is 
rarely  an  adequate  solution  to  these  problems. 


CONCLUSIONS 

Military  acquisition  is  moving  into  new  and  uncharted  waters.  The  use  of  COTS  products  as  the  basis  for  military 
systems  brings  many  advantages,  but  it  also  brings  many  challenges.  To  meet  these  challenges  will  certainly  require 
new  technical  skills  and  an  understanding  of  the  characteristics  of  COTS  within  procurement  organisations.  However, 
COTS-based  systems  also  bring  management  challenges,  many  of  which  run  counter  to  current  working  practices  in 
military  acquisition.  If  we  are  to  rise  to  these  challenges,  and  harness  the  potential  advantages  of  COTS,  then  a  change 
in  management  culture  and  philosophy  will  be  required,  allowing  the  introduction  of  new  management  approaches, 
representing  and  balancing  the  needs  of  all  stakeholders  in  government  and  industry. 
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Figure  1  -  Comparison  of  traditional  and  COTS -based  system  acquisition  lifecycles 
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Summary.  COTS  components  offer  a  solution  to 
many  obsolescence  problems,  but  certain  COTS 
items  can  also  introduce  their  own  difficulties. 
Commercial  operating  systems,  for  example,  play 
a  key  system  role  but  are  single-source  and  black 
box,  denying  the  user  both  the  visibility  and 
control  of  a  bespoke  item.  Open  source  software 
in  general,  but  the  Linux  operating  system  in 
particular,  seems  to  offer  many  of  the  advantages 
of  COTS  but  with  the  added  benefit  of  full  access 
to  the  source  code.  However,  the  widespread 
adoption  of  Linux  presents  not  only  opportunities 
but  some  potential  difficulties,  for  which  a 
possible  solution  is  a  dedicated  focus  within  the 
defence  community. 

Background  to  Paper.  The  Defence  Evaluation 
and  Research  Agency  (DERA)  is  the  prime 
source  of  research  for  the  UK  Ministry  of 
Defence  (MOD),  and  also  provides  a  major 
source  of  independent  advice  to  MOD  during  all 
stages  of  systems  procurement  and  deployment. 

The  Systems  and  Software  Engineering  Centre 
(SEC)  is  a  relatively  new  body  within  DERA, 
being  established  in  1994  to  act  as  a  focus  for 
professional  software  (and  soon  after,  systems) 
engineering  within  DERA.  The  majority  of  its 
complement  of  about  260  staff  have  an  industrial 
background. 

The  SEC  has  responsibility  for  the  systems  and 
software  standards  and  practices  used  across 
DERA  (which  has  a  staff  of  around  11,000).  It 
provides  the  editor  for  the  draft  ISO  standard 
(IS015288)  on  systems  engineering  and  is 
influential  in  setting  the  systems  engineering 
direction  of  MOD's  procurement  arm,  the  Defence 
Procurement  Agency  (DPA).  It  provides  systems 
and  software  engineering  support  to  a  wide  range 
of  programmes  within  DPA,  and  increasingly  to 
the  Defence  Logistics  Organisation  of  MOD.  The 
SEC  is  also  leading  in  the  field  of  capability 
assessment  and  evaluation,  eg  in  developing  and 
applying  various  Capability  Maturity  Models 
(CMMs).  The  author  is  the  SEC's  Technical 
Manager. 


Despite  this  background,  it  should  be  made  clear 
that  this  paper  does  not  constitute  the  results  from 
a  MOD-funded  research  programme,  nor  does  it 
represent  the  official  view  of  MOD,  DERA  or  the 
SEC.  Rather  it  captures  the  personal  views  and 
thinking  of  the  author.  However,  the  author  is 
pleased  to  acknowledge  the  rich  source  of  ideas 
he  has  encountered  in  the  SEC,  DERA,  MOD, 
Defence  Scientific  Advisory  Council  (DSAC) 
working  parties  and  other  contexts. 

Some  of  the  ideas  addressed  here  are  included  in  a 
recent  paper  in  the  Journal  of  Defence  Science, 
published  by  DERA. 

Introduction.  Commercial  components'  that  can 
be  used  in  defence  systems  may  take  several 
forms: 

•  A  common  commercial  item  from  the  civil 
world  (eg  a  PC  or  Land  Rover) 

•  A  specialised  item  from  the  civil  world  (eg  an 
inertial  navigation  system  box  for  an  aircraft) 

•  A  “standard”  item  from  the  defence  world  (eg 
a  gun  sight) 

•  An  item  that  has  been  used  before  but  just 
needs  “a  little  change”  to  make  it  meet  its 
new  purpose  -  especially  true  of  software 

•  A  small  component  (eg  a  processor  chip) 

•  A  full  service  (eg  satellite  communication) 

Whichever  kind  of  component  is  considered, 
there  are  some  common  issues  that  arise  when 
thinking  about  a  defence  system  in  which 
commercial  components  play  a  significant  part^. 
These  issues  are  highlighted  most  starkly  when 
the  item  is  a  truly  commercial  (COTS)  system 
component.  Hence,  this  is  the  case  considered  in 
this  paper. 


'  In  this  paper,  the  term  “component”  is  generally  used 
broadly  and  is  intended  to  encompass  sub-systems;  it  is 
not  intended  to  imply  the  lowest  level  in  a 
decomposition. 

^  While  acquisition  of  a  capability  might  be  more 
appropriate  to  consider  than  acquisition  of  a  system, 
systems  are  considered  for  convenience. 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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While  many  of  the  issues  discussed  apply  equally 
to  any  kind  of  COTS,  the  emphasis  of  this  paper 
is  on  software  items.  There  are  a  number  of 
reasons  for  this: 

•  Software  is  the  difficult  and  expensive  part  of 
most  systems 

•  Software  COTS  items  are  often  the  most 
sophisticated  and  complex  kind  of  component 

•  Many  software  COTS  items  change  rapidly 

COTS  and  Obsolescence.  COTS  items  have  a 
particular  attraction  when  considering 
obsolescence  management.  They  typically  have  a 
longer  lifetime  than  bespoke  components  because 
they  have  a  much  broader  customer  base  (or  at 
least  are  cheaper  over  a  given  lifetime  because 
maintaining  bespoke  items  is  expensive).  There 
is  also  often  an  opportunity  for  multi-sourcing 
that  is  very  significant. 

More  generally,  compared  with  a  bespoke 
approach,  a  COTS-based  development  often 
offers  many  advantages,  including: 

•  Reduced  costs 

•  Reduced  timescales 

•  Increased  reliability  through  exploitation  of 
proven  items 

•  Exploitation  of  civil  research  and 
development  (R&D)  investment,  which 
globally  has  far  outstripped  defence-focused 
R&D 

•  Accelerated  introduction  through  familiar 
user  interfaces  that  facilitate  training,  etc 

•  Increased  opportunity  for  multi- sourcing 
through  open  standards 

•  Improved  interoperability  between  defence 
systems  and  organisations,  through 
standardisation 

•  Improved  interoperability  between  defence 
and  non-defence  systems  and  organisations, 
again  through  standardisation 

It  is  important  to  note  that  a  COTS-based  solution 
will  not  necessarily  offer  all  these  advantages. 
For  example,  the  COTS  item  might  be  proprietary 
and  single-source,  while  still  delivering  all  the 
other  advantages  listed  above. 

Impact  of  COTS.  The  potential  benefits  are  thus 
great,  but  it  is  vital  to  consider  carefully  how  the 
use  of  COTS  impacts  some  key  areas: 

•  Military  capability 

•  Systems  development 

•  System  acquisition  and  support 


Capability.  COTS  is  a  powerful  influence 
towards  a  “level  playing  field”.  By  its  very 
nature,  a  COTS  component  must  be  considered  to 
be  available  to  any  country  and  organisation.  We 
must  assume  that  potential  enemies  can: 

•  Exploit  the  same  COTS  components  in  their 
own  systems 

•  Infer  how  we  might  use  them  in  our  systems 

•  Explore  their  weaknesses 

•  Develop  countermeasures  of  various  kinds 

•  Perhaps  exploit  upgrades  to  the  COTS 
components  faster  than  we  can 

Because  of  their  ubiquitous  nature,  COTS  items 
are  a  particularly  vulnerable  part  of  a  system. 
Where  the  item  is  something  like  an  operating 
system,  we  can  expect  any  flaw  such  as  a  security 
weakness  to  be  identified  very  publicly.  Perhaps 
more  dangerous  is  the  community  of  semi¬ 
underground  “crackers”  -  individuals,  and 
sometimes  organisations,  who  spend  time 
identifying  weaknesses  in  COTS  software  items 
and  then  publish  or  exchange  this  information  on 
the  Internet. 

Conversely,  it  is  possible  to  exploit  this  published 
information  and  counter  any  weaknesses  rapidly  - 
assuming  the  underlying  mechanisms  for  rapid 
upgrading  are  in  place,  a  crucial  point.  Of  course, 
if  the  affected  item  is  a  COTS  package  over 
which  we  have  no  direct  control,  the  best  we  can 
do  with  the  information  is  to  press  the  supplier  for 
a  fix  and  attempt  a  “work  around”  until  it  arrives. 

System  Development.  A  key  characteristic  of 
most  COTS  components  is  that  they  are  “black 
boxes”.  This  has  a  number  of  serious 
implications: 

•  We  cannot  be  sure  what  they  contain;  they 
may  have  in  them  -  perhaps  deliberately  - 
features  that  compromise  or  destroy  aspects 
such  as  security 

•  We  cannot  examine  how  they  achieve  their 
functionality;  we  cannot,  for  example,  apply 
techniques  such  as  static  code  analysis  when 
assessing  their  role  in  a  safety-critical  context 

In  practice,  some  component  suppliers  may  be 
willing  to  provide  internal  details,  although 
especially  where  national  boundaries  are  crossed, 
this  may  require  some  negotiation. 

System  Acquisition  and  Support.  The  impact 
of  COTS  on  acquisition  can  be  seen  most  clearly 
in  Table  1  that  compares  the  "traditional” 
approach,  in  which  the  customer  (say,  NATO) 
fully  specified  all  system  components,  to  a 
COTS-based  procurement. 
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TRADITIONAL 

COTS-BASED 

NATO  able  to  plan  and  control  system  development 

COTS  components  change  asynchronously  and 
rapidly 

NATO  able  to  define  functionality 

COTS  supplier  defines  functionality  to  suit  larger 
market.  NATO  spec  may  preclude  use  of  COTS  if  too 
rigid. 

NATO  able  to  control/view  development  process  to 
support  its  responsibilities  for  certification,  etc 

COTS  item  is  “black  box”  and  alternative  approaches 
to  certification,  etc  may  be  needed 

NATO  able  to  control  interfaces  and  interoperability 

Interoperability  may  be  enhanced  if  same  COTS 
component  in  both  systems,  but  otherwise  may  be 
very  difficult  because  COTS  interfaces  not  fully 
defined/maintained 

NATO  able  to  exploit  expertise,  standards,  etc  for 
component  engineering 

Key  activity  now  becomes  systems  integration  -  more 
of  a  “black  art” 

NATO  able  to  control  functionality 

COTS  supplier  may  define  upgrade  package  (eg 
operating  system  plus  applications) 

NATO  able  to  co-ordinate  change  to  component  with 
change  to  whole  system 

COTS  component  change  driven  purely  by 
commercial  factors,  not  synchronised  with  system 
constraints  (eg  refits).  May  lead  to  many  variants  of 
equipment  fit  across  fleet  of  platforms. 

NATO  able  to  procure  changes/fix  problems, 
especially  in  emergency,  perhaps  in  the  field 

COTS  component  changed  if  and  when  supplier  sees 
market  advantage;  NATO  not  a  significant  customer 

NATO  able  to  assume  component  will  remain 
available  (especially  components  that  wear  out) 

COTS  component  may  simply  cease  to  be  available 
(not  just  be  unsupported)  if  commercial  market  moves 
away  from  it 

Table  1  Traditional  v  COTS -Based  Acquisition 


Fundamental  characteristics  of  COTS  items  that 
might  he  exploited  in  NATO  systems  can  thus  he 
summarised  -  perhaps  rather  starkly  -  as: 

•  “Take  it  or  leave  it”  functionality 

•  Rapid  change 

•  Out  of  NATO  control 

contrast,  most  COTS  items  are  "black  box".  It  is 
generally  accepted  these  days  that  obscurity  is  not 
the  same  as  security  and  that  on  balance,  the 
interests  of  security  are  best  served  by 
transparency.  Again,  visibility  is  an  issue  that  is 
particularly  relevant  for  software  since  software  is 
generally  much  more  complex  and  flexible  that 

COTS  Software.  There  are  thus  two  key  issues 
that  apply  to  all  COTS  items  hut  which  are 
especially  problematical  for  COTS  software. 

The  first  is  control.  A  major  advantage  of 
bespoke  components  is  that  the  customer  can 
control  the  functionality,  interfaces,  schedule, 
upgrade  path,  etc.  Conversely,  with  COTS  items, 
the  customer  is  not  the  leader  but  the  led.  By  its 
nature,  COTS  software  is  subject  to  much  more 
variation  in  functionality  and  interfaces  than  a 
relatively  constrained  item  such  as  a  processor 
chip. 

The  second  issue  is  visibility.  Bespoke  software 
can  be  examined  to  ensure  it  does  not  include  any 
feature  to  prejudice  security,  safety,  etc.  In 

hardware. 

Within  the  field  of  COTS  software,  the  operating 
system  (OS)  is  especially  key.  It  is  central  to  the 
whole  capability  implemented  in  software  and  can 
be  very  complex.  It  also  pivotal  in  the  sense  that 
very  often  a  change  to  the  OS  for  whatever  reason 
can  mean  a  change  to  the  applications  running  on 
it.  This  is  particularly  troublesome  if,  for 
example,  a  change  of  OS  is  needed  to  fix  a  bug 
and  this  solution  only  comes  as  a  package  that 
introduces  new  problems,  in  the  shape  of  revised 
applications. 

It  is  interesting  to  note  that  in  this  way,  a  change 
to  the  COTS  OS  can  make  the  applications  that 
run  on  it  obsolete.  That  is,  the  COTS  system 
element  can  actually  make  proprietary  system 
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elements  obsolete  -  a  perhaps  unexpected 
situation.  Of  course,  this  usually  arises  where  the 
OS  is  COTS,  but  is  also  itself  proprietary  and 
single-source. 

Note  that  in  this  paper,  the  emphasis  is  on  general 
purpose  operating  systems  rather  than  more 
specialist  examples,  such  as  real-time  operating 
systems  for  embedded  processors. 

Addressing  the  Problems.  The  capability 
impact  addressed  above  -  eg  where  a  potential 
enemy  has  the  same  capability  as  ourselves 
through  using  the  same  COTS  item  -  requires  that 
we  undertake  a  much  broader  review  of  issues. 
Major  changes  in  strategy  may  be  driven  by 
answers  to  questions  such  as: 

•  Where  does  our  COTS-based  system  have  the 
edge  over  an  enemy’s  system  that  uses  the 
same  COTS  items? 

•  Where  are  the  weaknesses  in  our  system  that 
the  COTS  items  introduce?  How  might  an 
enemy  exploit  these?  What  countermeasures 
can  we  put  into  place? 

•  If  we  have  to  conclude  that  our  COTS-based 
system  does  not  offer  significant,  dependable 
superiority  of  technology,  is  there  some  other 
source  of  military  advantage  for  us,  such  as 
superiority  of  training  or  numbers? 

The  systems  design  issues  -  when  we  no  longer 
have  visibility  of  the  internal  behaviour  of  the 
COTS  item  -  implies  that  we  have  to  consider 
means  of  containing  any  undesirable  behaviour 
and  preventing  it  impacting  on  the  rest  of  the 
system.  Such  approaches  often  take  the  form  of 
“wrapping”  of  some  kind,  but  introducing  parallel 
COTS  components  from  different  sources  and 
using  voting  may  be  an  alternative  in  some 
circumstances. 

Also  key  for  system  design  is  the  question  of 
standards.  COTS  components  are  usually 
associated  with  standards  of  various  kinds.  These 
standards  may  address  the  interfaces/ 
interoperability  of  the  item  and/or  its 
functionality.  Standards  may  be  de  jure,  typically 
endorsed  by  an  international  standards  body  or 
broad-based  industry  group,  or  de  facto,  typically 
set  by  a  single,  dominant  supplier. 

In  either  case,  the  choice  of  standard  during 
development  is  crucial.  Important  questions 
include: 

•  How  stable  is  the  standard? 

•  How  definitive  is  it?  (eg  can  widely-differing 
items  both  claim  compliance?) 

•  How  many  vendors/products  support  the 
standard  now? 

•  How  many  will  support  it  in  the  future? 


•  Is  any  replacement  standard  likely  to  offer 
upwards  compatibility? 

Of  course,  standards  are  most  important  from  an 
obsolescence  viewpoint  if  the  strategy  is  to  use 
them  to  define  a  “hole”  in  the  system  into  which 
can  be  “plugged”  a  variety  of  products  from  a 
variety  of  suppliers,  all  of  which  “fit”.  This  is  one 
approach,  but  in  some  areas,  others  are  also 
possible. 

The  Best  of  Both  Worlds?  As  noted  above,  the 
key  issues  for  "traditional"  COTS  software  are 
control  and  visibility.  These  are  the 
characteristics  that  have  to  be  traded  off  against 
the  advantages  offered  by  a  COTS  item. 
However,  one  class  of  software  component  does 
appear  to  offer  the  best  of  the  bespoke  and  COTS 
worlds:  open  source  software. 

Open  source  software  is  freely  available  to  all 
interested  parties.  It  may  be  copied,  changed  and 
distributed  onwards.  Thus  to  all  intents  and 
purposes,  it  can  be  owned  in  the  same  way  as 
bespoke  software.  However,  it  may  not  be  totally 
without  restriction.  For  example,  usually  it  is 
licensed  and  the  licence  stipulates  that  if  it  is 
changed  then  the  modified  version  cannot  be 
redistributed  unless  it  too  is  freely  available. 

Open  source  software  (OSS)  therefore  offers  the 
control  and  visibility  of  bespoke  software  while  at 
the  same  time  avoiding  the  cost  and  risk  of 
developing  the  software  from  scratch. 

Furthermore,  the  OSS  items  tend  to  be  exploited 
and  modified  by  a  wide  community  of  users 
across  the  globe,  communicating  via  the  Internet. 
The  OSS  item  is  thus  essentially  “owned”  by  a 
wide  community  of  enthusiastic  people  who  want 
to  see  it  succeed.  Because  the  source  is  available 
to  them,  they  are  able  to  identify  problems  by 
analysing  the  code  rather  than  simply  waiting 
until  some  erroneous  behaviour  is  spotted.  They 
are  also  able  -  and  motivated  -  to  devise  solutions 
and  disseminate  these  to  others. 

This  cultural  dimension  of  OSS  is  a  very 
significant  factor  in  its  success. 

Linux.  The  best  known  example  of  OSS  is 
undoubtedly  Linux.  It  is  important  to  note  that 
some  of  the  ways  Linux  has  developed  and  its 
current  position  are  not  necessarily  typical  of 
other  OSS  items,  and  OSS  components  do  not 
necessarily  have  to  follow  the  Linux  model. 
However,  Linux  is  so  significant  that  it  deserves 
attention. 

Strictly,  Linux  is  an  operating  system  consisting 
of  the  kernel  (that  provides  the  basic  mechanisms 
for  scheduling,  etc)  and  device  drivers  that  allow 
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it  to  communicate  with  various  peripherals. 
However,  in  practice,  the  term  is  also  used  to 
apply  to  a  wider  collection  of  items,  including,  for 
example,  a  graphical  user  interface. 

The  strict  interpretation  is  useful  to  hear  in  mind 
since  while  the  kernel  is  essentially  standardised 
(see  helow),  there  are  a  number  of  different 
options  -  virtually  all  open  source  themselves  - 
that  exist  for  the  applications  that  go  with  the 
kernel  to  make  it  an  “operating  system”  in  the 
Microsoft  Windows  sense  -  ie  the  kernel  plus  a 
whole  host  of  other  things  that  actually  allow  the 
user  to  do  something  useful.  Thus  the  various 
Linux  packages  (“distrihutions”)  that  are 
available  from  a  variety  of  suppliers  all  provide  a 
different  set  of  items  together  with  the  standard 
Linux  core. 

The  Linux  kernel  is  essentially  controlled  by  the 
originator  of  Linux,  Linus  Torvalds.  Typically, 
somebody  in  the  world  will  identify  the  need  for  a 
new  feature  and  publish  a  very  early  and 
imperfect  version  of  it.  Others  will  use  and  refine 
this,  also  publishing  their  work.  Eventually,  the 
item  will  become  stable  and  widely  used  and  then 
accepted  into  the  “official”  version  by  Torvalds. 

There  are  several  implications  of  this,  of  course. 
On  the  positive  side,  it  is  very  visible  in  which 
way  the  product  is  moving  and  interested  parties 
can  at  the  very  least  monitor  this.  They  can  also 
influence  it  if  they  are  prepared  to  actually 
contribute  development  effort.  The  disadvantage 
is  that  in  fact  it  may  be  moving  in  conflicting 
directions  (eg  there  are  currently  a  number  of 
different  hard  real-time  extensions  being 
developed)  and  the  final  outcome  might  not  be  at 
all  clear. 

There  is  also  an  obvious  issue  over  the  role  of 
Torvalds  as  the  arbiter  of  what  constitutes  a 
formal  release  of  Linux.  His  role  is  vital  in 
deciding  when  a  new  release  occurs  and  what  it 
contains,  and  as  the  system  grows  this  becomes 
ever  more  demanding.  Already,  there  are  some 
indications  that  releases  are  slipping  behind 
schedule  (eg  version  2.4).  There  is  also  some 
uncertainty  about  what  will  happen  when 
Torvalds,  for  whatever  reason,  relinquishes  this 
role. 

Technically,  Linux  is  a  flavour  of  Unix,  although 
it  is  worth  noting  that  it  does  not  fully  comply 
with  the  Open  Group’s  criteria  that  would  allow  it 
to  use  the  Unix  trademark.  Partly  due  to  the  way 
it  has  been  developed,  it  is  very  modular  and  has 
a  relatively  low  number  of  system  interfaces 
when  compared  to  Windows,  for  example  (230 
rather  than  3500). 

A  key  feature  is  that  Linux  has  been  implemented 
on  a  very  wide  range  of  machines.  This  is 
facilitated  by  its  modularity  and  relative 


simplicity,  making  it  possible  to  run  it  on  “bottom 
end”  architectures. 


Other  (Open  Source)  Software.  The  same  basic 
approach  to  development  that  has  proved  so 
popular  for  Linux  has  been  adopted  for  many 
other  pieces  of  software,  although  a  lot  have 
followed  a  more  traditional,  and  some  would  say 
more  controlled,  development  process.  Not 
surprisingly,  most  other  OSS  items  are  designed 
to  run  on  Linux  and  many  provide  the 
functionality  that  users  have  come  to  see  as 
essential,  eg  a  graphical  user  interface. 

Literally  thousands  of  open  source  developments 
are  under  way,  although  these  vary  immensely  in 
what  they  offer  to  typical  end-users  (as  opposed 
to  computer  systems  engineers,  for  example)  and 
there  is  much  duplication. 

Office  software,  some  open  source,  and  other 
applications  such  as  databases  (eg  from  Oracle) 
are  available  to  run  on  Linux.  One  particularly 
outstanding  example  of  an  open  source 
application  is  the  Apache  web  server  software  and 
some  estimates  give  Apache  and  Linux 
respectively  a  60%  and  30%  share  of  all  web 
servers  on  the  Internet.  Products  such  as  WINE 
allow  Windows  applications  to  run  on  Linux. 

Despite  all  these  initiatives,  though,  the  current 
situation  is  that  Linux  has  a  far  less  rich  set  of 
applications  available  for  it  than  has  Windows. 
However,  in  the  field  of  palmtops  and  similar 
devices,  where  the  processing  power  is  relatively 
limited  and  unit  costs  for  the  operating  system  are 
significant,  Linux  may  easily  gain  the  edge. 

Linux  and  Obsolescence.  Linux  offers  some 
significant  advantages  when  combating 
obsolescence,  but  also  raises  some  issues. 

Advantages.  As  noted  above,  the  operating 
system  is  a  crucial  element  of  the  system  when 
considering  obsolescence.  Because  it  is  open 
source,  Linux  has  some  vital  advantages  over  a 
commercial,  closed  source  OS: 

•  Changes  for  bug  fixes  etc  can  be  made  in 
whatever  way  is  appropriate,  eg  to  retain  the 
same  interfaces  for  applications  so  that  they 
do  not  need  to  change 

•  Hardware  can  be  added  or  changed  relatively 
easily  since  the  drivers  are  readily  accessible, 
and  porting  can  be  undertaken 

•  Changes  to  accommodate  new  requirements 
can  be  made  as  needed 

Of  course,  these  benefits  arise  simply  because  we 
have  access  to  the  source  code,  with  all  that  gives 
in  terms  of  visibility  and  control.  In  addition. 
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there  are  advantages  that  come  from  the  “Linux 
culture”: 

•  Others  may  have  already  developed  and 
published  a  solution  to  the  obsolescence 
problem 

•  If  not,  it  may  be  possible  to  reduce  cost  and 
timescales  by  collaborating  with  others  who 
share  the  problem 

•  A  major  element  in  combating  obsolescence 
is  having  a  plan  for  how  future  versions  of  the 
system  will  change  to  meet  future  needs,  and 
there  is  great  visibility  of  future  Linux 
developments 

Thus  both  the  availability  of  the  source  and  the 
broad  development  model  of  Linux  offer  many 
advantages.  Naturally,  though,  there  are  some 
issues  to  be  addressed. 

Issues.  If  a  customer,  eg  NATO  or  one  of  its 
member  Ministries  of  Defence,  decides  using 
Linux  in  its  systems  is  desirable,  specifying  this 
for  a  supplier  is  not  trivial.  Because  of  its 
modular  nature  and  the  wide  variety  of 
“distributions”  available,  a  comprehensive  list  of 
modules,  applications,  etc  is  needed  rather  than  a 
simple  specification  like  “Windows  NT  version 
4”. 

Much  more  significant  is  the  question  of  how 
Linux  might  be  exploited  across  a  range  of 
systems.  Because  of  its  portability  and 
scalability,  Linux  lends  itself  to  being  used  on 
many  hardware  architectures  and  there  are 
obvious  advantages  in  adopting  it  as  a  common 
platform.  As  well  as  countering  obsolescence  in 
the  ways  already  discussed,  this  would  also 
increase  opportunities  for  re-use. 

However,  once  we  have  a  range  of  systems  all 
using  Linux,  how  do  we  manage  the  problem  of 
upgrades,  bug  fixes,  etc?  A  whole  spectrum  of 
options  exist.  We  can  simply  highlight  the 
problem  and  wait  for  the  Linux  community  to 
solve  it.  This  is  directly  analogous  to  the  position 
with  Microsoft  and  Windows.  At  the  other 
extreme,  we  can  actually  make  the  change 
ourselves.  We  can  also  collaborate  with  other 
interested  parties.  In  practice,  it  may  be  necessary 
to  adopt  a  mixture  of  approaches,  depending  on 
individual  circumstances. 

A  key  question  for  defence  systems  with  their 
typically  long  lives  is:  how  long  will  the  Linux 
community  exist  as  it  does  now?  Answering  this 
requires  predicting  the  future,  of  course,  and  so 
cannot  be  definitive,  but  the  author’ s  views  are  as 
follows. 

Since  the  early  1990’s  the  Linux  community  has 
grown  rapidly  to  a  size  now  of  around  10  million. 
It  is  clear  from  looking  at  the  various  related  web 


sites  that  there  is  a  strong  element  of  enthusiasm 
for  the  technical  strengths  of  Linux,  a  major 
academic  involvement,  and  a  hint  of  religious 
wars  against  Microsoft  and  closed  source 
software  (not  necessary  all  at  the  same  time!). 
There  are  also  echoes,  for  those  old  enough  to 
remember,  of  the  “Unix  is  about  to  rule  the 
world”  messages  that  have  been  appearing 
periodically  over  the  last  25  years  or  so.  Thus 
while  the  popularity  of  Linux  is  still  growing, 
there  is  always  the  risk  of  something  new 
catching  the  community’s  imagination  as  time 
passes. 

Linux  will  never  achieve  the  total  market 
penetration  of  Windows,  which  despite  its  failings 
will  remain  the  dominant  operating  system  for 
desktops  at  least.  Issues  such  as  backwards 
compatibility  and  migration  paths  will  be  of  less 
concern  to  the  Linux  community  than  to 
Microsoft  (although  the  Microsoft  route  may  not 
be  easy  and  the  “do  it  yourself’  option  is  always 
available  for  Linux). 

Thus  while  Linux  will  not  disappear  altogether,  it 
seems  very  unlikely  that  in  20  years’  time  - 
perhaps  even  10  -  the  community  will  exist  as  it 
does  now.  In  many  ways,  Linux  will  then  itself  be 
obsolete!  Given  the  cultural  environment  in 
which  Linux  has  flourished,  it  may  even  be  that 
visible  exploitation  by  the  defence  community 
might  hasten  this  shrinking  of  global  support. 

This  does  not,  of  course,  mean  that  the  defence 
world  should  dismiss  Linux.  What  it  does  mean, 
though,  is  that  if  it  is  to  adopt  it  widely,  it  must 
address  this  long-term  issue. 

A  separate  issue  is  related  to  the  special  defence 
needs  of  considering  security,  safety,  etc.  In 
principle,  the  answer  is  easy  because  all  the  Linux 
source  is  visible.  In  practice,  although  Linux  is 
relatively  simple  compared  with  other  operating 
systems,  understanding  adequately  how  it  behaves 
is  not  easy. 

More  generally,  even  while  a  large  Linux 
community  exists,  it  can  only  be  relied  upon  to 
provide  some  change  if  that  modification  has 
broad  enough  appeal.  If  the  defence  world  is 
likely  to  need  some  more  arcane  work  done  (eg 
interfacing  to  a  specialist  device)  -  especially  if  it 
is  urgent  -  then  it  is  likely  to  be  in  the  position  of 
needing  to  be  capable  of  doing  it  itself. 

Finally,  but  by  no  means  least  important,  is  the 
question  of  verification  and  validation  and 
confidence  that  the  rather  special  way  in  which 
Linux  is  developed,  released  and  controlled  can 
provide  a  product  that  is  suitably  robust. 

Again,  the  fact  that  the  source  is  available,  there 
is  a  large  community  of  interest  and  Linux  is 
relatively  simple  all  help  to  suggest  that  at  least  if 
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a  problem  is  found,  it  will  be  relatively  easy  to 
overcome.  Neither,  despite  the  impression  its 
background  might  form  in  some  minds,  is  it  really 
obvious  that  Linux  starts  off  any  more  likely  to  be 
faulty  than  a  commercial  OS.  Nevertheless,  this 
remains  an  issue  to  be  addressed. 

A  Solution. 

If  the  advantages  of  Linux  are  to  be  exploited,  one 
way  forward  is  to  establish  a  “Linux  Centre”  for 
the  domain  of  interest,  eg  the  UK  MOD  or 
NATO.  This  Linux  Centre  could  then  act  as  the 
focus  for  Linux  use  across  a  number  of  systems  in 
the  customer’ s  domain,  see  Figure  1 . 


Global  Linux  Community 


Figure  1  The  Linux  Centre 


In  particular  the  Linux  Centre  could: 

•  Be  the  repository  for  knowledge  especially 
relevant  to  the  domain  (eg  on  security/safety 
issues) 

•  Offer  the  skill  base  necessary  to  make 
changes  that  for  one  reason  or  another  cannot 
come  from  elsewhere 

•  Provide  additional  verification  and  validation 
functions  to  increase  confidence  in  the  Linux 
versions  used 

•  Ensure  commonality  to  whatever  extent  is 
appropriate,  eg  by  defining  the  “standard” 
Linux  distribution 

•  Synchronise  upgrades,  etc  so  that 
commonality  is  maintained 

•  Retain  knowledge  of  older  versions  where 
appropriate 

•  Act  as  a  clearinghouse  for  proposed  changes 
to  Linux:  providing  synchronisation  across 
projects  within  the  domain,  supporting 
synergy  between  activities  on  separate 
projects,  etc 


•  Act  as  an  interface  to  the  wider  Linux 
community 

•  Retain  knowledge,  skills,  etc  as  and  when  the 
larger  community  contracts 

In  essence,  therefore,  the  Linux  Centre  would  be  a 
mirror  within  the  specific  defence  community  of 
the  broader  Internet  foci  that  exist,  such  as 
Torvalds  and  various  Internet  sites.  It  would 
enable  this  broader  community  to  be  exploited, 
but  reduce  dependency  on  it. 

Within  the  domain  of  defence  systems,  it  would 
be  important  that  the  open  source  culture  survived 
as  far  as  possible,  with  projects  interacting  within 
themselves  and  more  widely  to  produce  rapid  and 
collaborative  solutions.  However,  the  extra  focus, 
synchronisation  and  longevity  of  the  Linux  Centre 
would  ensure  maximum  benefit  across  the 
defence  enterprise. 

There  are  many  options  for  the  organisational 
form  of  the  Linux  Centre.  Some  of  the  aspects 
related  to  safety,  for  example,  might  be  common 
with  many  non-defence  domains,  so  sharing  could 
take  place.  Also,  support  is  commercially 
available  now  from  a  number  of  companies  and  it 
may  be  that  some  at  least  of  these  companies 
continue  to  offer  support  as  the  general 
community  declines. 

A  Linux  Centre  is  not  without  its  own  difficulties. 
As  noted  above,  its  mere  existence  may  diminish 
the  global  support  for  Linux  and  thus  undermine 
a  key  reason  for  using  Linux  in  the  first  place ! 

Even  an  open  source  approach  just  within  a 
limited  defence  community  (eg  on  a  national 
basis)  raises  issues  of  multi-project,  multi¬ 
organisation  working  that  would  require  a  major 
re-think  of  some  traditional  attitudes  in  both 
procuring  and  supplying  organisations. 

There  is  also  a  question  over  balancing  the  open 
source  culture  of  rapid  “try  it  and  see”  refinement 
through  collaboration  with  more  traditional  needs, 
practices  and  attitudes  that  tend  to  reflect 
increased  levels  of  control. 

However,  widespread  adoption  of  Linux  without 
addressing  these  sort  of  issues  entails  a  risk  of 
being  hit  by  what  is  essentially  the  obsolescence 
of  Linux,  with  a  much  greater  impact  than  if  one 
had  stayed  with  Microsoft! 

The  Open  Source  Future.  Will  the  trend 
towards  open  source  software  in  areas  other  than 
the  operating  system  continue?  Probably  yes. 

Operating  systems  are  at  the  bottom  of  the 
OS/applications/service  hierarchy  of  possible 
products  vendor  organisations  might  offer. 
Operating  systems  are  no  longer  a  major  value 
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item  for  vendor  or  customer,  and  it  is  perhaps  not 
surprising  that  the  first  real  open  source  success  is 
Linux.  As  the  focus  shifts  more  and  more  up  the 
hierarchy,  then  the  more  likelihood  there  is  of  the 
levels  that  are  “left  behind”  becoming  open 
source  as  their  value  reduces: 


On  the  other  hand,  the  open  source  development 
model  only  has  maximum  value  where  there  is  a 
large  community  of  interest  who  are  enthusiastic 
to  participate.  As  one  climbs  the  hierarchy,  there 
is  an  inevitable  narrowing  of  interest  as 
specialism  increases.  Another  factor  is  the 
relative  level  of  involvement  of  the  academic 
community,  which  may  be  different  for  operating 
systems  and  word  processors,  say. 

On  balance,  though,  open  source  items  seem 
likely  to  be  a  significant  feature  of  the  software 
world  for  some  time. 


Conclusion. 

COTS  items  do  offer  major  advantages  in 
combating  obsolescence,  but  their  use  does 
introduce  other  issues  that  must  be  addressed  in  a 
variety  of  ways. 

The  advantages  are  reduced  if  the  COTS  item  is 
single-source  and  black  box.  In  these 
circumstances,  the  vital  aspects  of  visibility  and 
control  are  severely  weakened,  if  not  lost 
altogether.  Unfortunately,  the  operating  system  is 
one  key  system  element  that  typically  does  have 
these  undesirable  attributes. 

Linux,  as  an  open  source  operating  system  with  a 
very  active  user/developer  community,  offers 
much  of  the  best  of  both  worlds.  It  does  not  have 
to  be  developed  from  scratch,  yet  can  be  as  visible 
and  under  control  as  a  bespoke  item.  Also,  it  has 
already  been  ported  to  many  hardware 
architectures,  offering  the  possibility  of  a  standard 
platform  across  a  whole  range  of  systems,  with 
attendant  opportunities  for  re-use,  etc.  Similarly, 


it  offers  the  prospect  of  relatively  easy  porting  to 
new  architectures  in  the  future. 

However,  Linux  provides  a  much  less  rich  set  of 
applications  than  Windows  and  this  seems  likely 
to  remain  the  case.  In  addition,  the  wide 
community  of  interest  that  has  driven  its  success 
so  far  may  well  not  be  sustained  over  the  long 
term.  Even  in  the  short  term,  the  community 
addresses  problems  that  are  of  interest  and  value 
to  itself,  and  these  may  not  coincide  with  defence 
system  needs. 

Thus  while  adoption  of  Linux  is  undoubtedly  an 
attractive  prospect  in  some  ways,  its  widespread 
use  introduces  a  number  of  issues.  One  way  to 
address  these  is  the  establishment  of  a  Linux 
Centre  that  can  be  a  focus  for  defence  needs  and 
provide  some  degree  of  dedicated  capability  while 
still  exploiting  the  broader  community. 

In  addition,  if  the  open  source  culture  of  rapid 
development  and  collaboration  is  to  be  retained, 
some  change  in  approach  from  procurer  and 
suppliers  will  be  required. 

More  generally,  the  open  source  model  is  likely  to 
spread,  although  its  extent  is  difficult  to  predict. 
On  balance,  open  source  software  provides  a 
major  opportunity  to  address  at  least  some  aspects 
of  obsolescence.  It  should  be  exploited,  but  will 
require  steps  like  those  proposed  for  Linux  to  gain 
its  full  potential. 
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Summary 

The  Reduced  Total  Cost  of  Ownership  (RTOC)  Study  was  a  unique,  “out-of-the-box”,  integrated  Science 
&  Technology  (New  Processes  &  Techniques)  approach  to  obtaining  more  affordable  aircraft  weapon 
systems  and  modernizing  these  systems  for  future  combat  scenarios.  The  RTOC  Study  stands  in  contrast  to 
the  individual  “bits  &  pieces”  technology  transition  plans  seen  in  the  past.  Individual  plans  can  result  in 
costly  programs  that  are  hard  to  justify  and  are  easily  attacked  when  evaluating  fiscal  parameters.  An 
integrated  Reduced  Total  Ownership  Cost  (RTOC)  approach,  with  substantiation  data  provided  by  the 
proposed  follow-on  effort,  would  be  easily  justified  by  these  same  fiscal  parameters  using  this  new  cost 
database. 

Background 

Affordability  has  become  the  number  one  issue  to  today’s  military  planners.  This  affordability  thrust, 
however,  is  slightly  different  than  those  of  the  past.  This  time  this  thrust  is  being  driven  out  of  “need”. 

As  stated  in  Figure  1,  today  forty-one  percent  (41%)  of  the  United  States  Air  Force  (USAF)  total  inventory 
is  over  24  years  old.  By  the  year  2005,  seventy-five  percent  (75%)  of  the  total  inventory  will  be  over  20 
years  old.  The  B-52  and  KC-135  will  be  approaching  60  and  80  years  of  duty,  respectively,  at  their 
currently  planned  retirement  dates.  The  cost  of  sustaining  this  aging  inventory  as  a  viable  military  force 
continues  to  increase  for  several  reasons:  economic  obsolescence,  high  operations  tempo,  aging  of  aircraft 
subsystems,  new  operational  techniques,  and  a  reduction  in  experience  level  of  the  maintainer  just  to 
mention  a  few.  While  solutions  are  available  to  maintain  these  weapon  systems  as  viable  2  F‘ Century 
vehicles,  in  most  cases,  the  non-recurring  cost  is  prohibitive.  The  funding  for  these  upgrades  must  compete 
with  basic  fleet  maintenance  and  other  modernization  activities. 

In  those  cases  where  technology  insertion  has  been  implemented,  it  usually  has  been  by  individual 
subsystem  upgrades,  a  “bits  &  pieces”  approach.  While  such  an  approach  can  meet  key  operational  needs 
and  reduce  subsystem  maintenance,  the  stand-alone  upgrade  bears  the  entire  development  and 
implementation  costs  by  itself.  Additionally,  stand-alone  upgrades,  while  improving  Reliability  & 
Maintainability  (R&M)  of  individual  system,  may  not  impact  the  total  weapon  system  R&M  performance. 
If  the  integrated  weapon  system  R&M  performance  is  not  improved,  the  weapon  system  will  experience  a 
lower  operational  readiness  and  potentially  a  reduced  combat  effectiveness.  This  could  be  labeled  as  an 

Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
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“unbalanced”  O&S  design.  The  benefits  of  technology  insertion  can  be  lost  if  the  cost  of  implementation  is 
considered  “too  high  for  the  benefits  achieved”.  Arriving  at  a  realistic  “business  case”  for  implementation 
of  a  given  technology  is  as  important  as  developing  the  technology  itself.  In  the  case  of  many  technologies, 
however,  it  may  be  that  traditional  estimating  models  do  not  adequately  account  for  the  technical  and/or 
process  benefits  afforded  or  the  current  database  is  inadequate  to  predict  the  cost  and/or  the  savings.  The 
“bits  &  pieces”  upgrade  philosophy,  coupled  with  tightly  constrained  budgets,  have  precluded  the  ability  to 
create  the  data  required  for  establishing  an  integrated  cost  model  for  new  technology. 

Study  Objectives/  Requirements 

The  RTOC  Study  had  the  following  major  objectives.  The  first  major  objective  was  to  validate  that 
technology  can  reduce  the  life  cycle  cost  of  an  aircraft  by  40  to  60  percent.  The  baseline  aircraft  for  this 
study  was  an  existing  aircraft  that  has  an  extensive  cost  database  and  weight  and  volume  trade  space  for 
meaningful  R&M  studies.  The  study’s  focus  was  on  acquisition,  RDT&E,  and  O&S  cost  savings.  The 
current  Air  National  Guard  operations  tempo  and  basing  was  used  to  formulate  cost  comparisons. 

The  second  objective  focused  on  critical  aircraft  design  and  assembly  processes  with  the  idea  of 
“Revolutionizing  the  Aircraft  Industry”.  Critical  design  and  assembly  processes  necessary  to  achieve  the 
full  benefit  of  the  new  technologies  must  be  identified  and/or  defined.  These  processes  support  the 
elimination  of  Programmed  Depot  Maintenance  (PDM),  provide  efficient  growth  in  aircraft  systems,  utilize 
the  new  cost  implementation  models,  reduce  the  cost  sensitivity  to  production  rates/line  breaks,  and  achieve 
sustainable  high  levels  of  R&M  over  the  life  cycle  of  the  weapon  system 

Two  key  requirements  for  the  RTOC  Study  were  (1)  the  primary  mission  would  be  air-to-air,  and  (2)  the 
current  mission  performance  could  not  be  reduced.  The  configuration  defined  during  the  study  met  these 
criteria,  but  possessed  a  robust  air-to-ground  potential  and  a  significant  mission  growth  capability.  This 
configuration  also  allows  for  an  easy  conversion  to  a  two-seat  variant  for  future  growth  and  flexibility  to 
accommodate  future  technology  demonstration  tasks. 

Figures  2&3  show  the  problem  in  historical  terms.  We  are  all  used  to  the  cost  estimating  relationships 
being  expressed  as  log-log  curves  as  shown  in  figure  2.  The  problem  with  using  these  curves  is  that  we 
have  lost  not  only  the  historical  data  on  them  but  also  we  do  not  know  how  these  curves  have  been 
impacted  by  the  need  for  obtaining  the  utmost  in  performance  at  any  cost.  This  chart  graphically  shows  the 
problem.  We  are  very  comfortable  in  estimating  cost  between  the  top  two  lines.  But  technology 
demonstration  programs  have  shown  that  we  can  get  down  to  the  lower  line.  The  problem  is  getting  the 
cost  community  to  accept  this  as  the  current  state  of  the  art.  The  cost  community  includes  everyone  in  that 
process  from  the  initial  engineering  estimate  to  the  final  cost  that  we  see  in  the  formal  proposal. 

The  second  area  where  cost  estimating  relationships  are  not  able  to  capture  the  impact  of  technology  is  the 
learning  curve  as  shown  in  figure  3.  This  chart  is  another  example  of  the  cost-estimating  dilemma.  This  is  a 
learning  curve.  It  is  used  to  adjust  the  historical  data  over  the  projected  buy  and  the  efficiency  introduced 
when  you  build  the  same  thing  over  and  over  again.  Where  you  draw  this  curve  makes  a  big  impact  on  the 
cost  of  you  first  articles  and  total  program  costs.  Today’s  technologies  are  driving  this  curve  to  a  nearly 
straight  horizontal  line.  This  says  that  costs  could  be  independent  of  quantity  buys.  That  is  the  first  article 
costs  as  much  to  build  as  the  last  article.  This  is  a  significant  impact  on  program  costs  and  says  that  in  the 
extreme  you  could  be  independent  of  production  line  break,  as  there  is  little  learning  curve  to  retain.  With 
virtual  reality,  we  are  now  able  to  build  and  assemble  a  large  structure  many  times  in  the  computer  and 
with  the  latest  technology  we  are  now  close  to  making  this  curve  essentially  a  horizontal  line. 


Technology  Maturity 

One  important  factor  to  be  considered  in  a  study  of  this  kind  is  to  ensure  that  any  proposed  technology  has 
an  appropriate  maturity  in  order  to  manage  risk  and  avoid  cost  overruns.  One  tool  for  assessing  this  is 
known  as  Technology  Readiness  Level  (TRL),  see  Figure  4.  The  TRL  goes  from  a  value  of  1  for  a  basic 
idea  through  a  defined  range  up  to  a  value  of  9  for  something  in  'operational  use'.  These  values  must  be 
qualified  in  more  detail  depending  on  various  factors.  If  the  technology,  or  component,  is  in  operational 
use  on  a  different  military  aircraft  system  then  there  is  little  question  about  the  TRL.  Only  the  integration 
issues,  or  changes  required,  need  to  be  analyzed  for  a  credible  assessment  to  be  made.  On  the  other  hand. 
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Commercial  Off  The  Shelf  (COTS)  equipment  is  popularly  considered  to  be  a  potential  cost  saver  for 
military  applications.  Something  that  is  in  routine  commercial  use  may  still  need  qualifying  for  different 
environmental  factors.  It  is  also  possible  that  it  can  be  decided  that  there  is  no  significant  difference  and  a 
TRL  of  8  can  be  assumed  for  application.  One  factor  that  will  have  a  strong  influence  on  the  analysis  is 
whether  the  technology  under  consideration  is  considered  flight  safety  critical,  or  mission  critical,  or  less 
critical.  Obviously,  flight  safety  critical  items  will  receive  the  closest  scrutiny.  We  can  consider  the  flight 
control  system  to  be  in  this  category  and  will  be  discussed  as  an  example. 

The  F-15is  a  good  illustration  of  the  process  because  it  has  a  mechanical  flight  control  system  that  is  a 
significant  maintenance  item.  New  high-performance  fighters  are  designed  with  digital  control  systems  for 
reasons  of  cost  and  performance,  and  such  a  change  must  be  a  consideration  for  the  study.  There  is  no 
COTS  possibility,  the  military  are  ahead  of  all  commercial  applications  in  this  area  because  of  the  flight 
envelope  and  maneuverability  requirements.  Replacing  the  mechanical  system  with  a  new  design  would  be 
a  significant  development  effort.  In  order  to  avoid  the  cost  of  developing  a  new  PCS,  we  must  look  at  other 
possibilities.  In  terms  of  a  system  in  operational  use  (to  maximize  the  TRL),  we  might  consider  the  F/A- 
18E/F.  While  there  would  be  many  similarities,  the  control  laws  for  carrier  landing  would  certainly  need  to 
be  modified  for  USAF  operation.  Next  we  can  consider  a  control  system  that  has  flown  in  research 
programs.  Both  the  STOL  &  Maneuver  Technology  Demonstration  (S/MTD)  program  and  the  Advanced 
Control  Technology  for  Integrated  Vehicles  (ACTIVE)  program  have  used  an  E-15  to  conduct  thrust 
vectoring  research  programs.  The  S/MTD  flight  control  system  was  designed  with  a  new  digital  control 
system  with  no  dissimilar  backup  and  first  flew  in  1988.  A  primary  objective  of  the  program  was  to 
integrate  thrust  reversing  and  pitch  vectoring  into  an  integrated  Elight/Propulsion  Control  system.  The 
control  system  also  included  a  reversionary  mode  that  did  not  use  any  of  the  propulsive  control  components 
as  a  reference  for  the  other  research  control  modes.  Referred  to  as  the  CONVENTIONAL  mode,  it  enabled 
the  aircraft  to  fly  and  feel  to  the  pilot  like  a  normal  E-15  but  with  subtle  improvements.  After  the  S/MTD 
program  finished,  the  same  testbed  was  modified  to  incorporate  pitch/yaw  vectoring  nozzles  for  the 
ACTIVE  program.  The  same  CONVENTIONAL  mode  was  retained  and  flight  testing  has  continued  to 
this  date.  This  hardware  could  be  considered  to  be  at  a  TRL  of  8,  i.e.  flight  qualified  through  test  and 
demonstration.  The  control  laws  and  software  of  the  mode  might  be  considered  at  a  TRL  of  7,  although  it 
has  been  operating  successfully  for  twelve  years  it  has  not  been  cleared  for  unrestricted  flight  throughout 
the  E-15  envelope. 

The  preceding  discussion  is  intended  as  an  example  of  a  process  that  can  be  used  to  help  in  ranking 
competing  technologies  or  alternatives.  It  is  intended  to  reduce  some  of  the  subjectivity  in  assessing  the 
readiness  of  technologies,  both  hardware  and  software,  for  application  in  a  production  system. 

Study  Results 

The  study  duration  was  nine  months  and  the  deliverables  included  the  definition  of: 

(1)  A  reference  aircraft  configuration  that  would  reduce  Total  Ownership  Cost, 

(2)  The  identification  of  new,  robust  design  and  assembly  procedures  that  when  implemented 
would  incorporate  new  technologies  and  processes. 

(3)  Identification  of  new  maintenance  and  supply  concepts  that  reduce  the  Life  Cycle  Costs. 

Because  the  study  was  only  nine  months  long,  we  concentrated  on  the  life  cycle  elements  highlighted  in 
figure  5.  This  is  significant  in  that  later  on  in  the  paper  you  will  see  substantial  savings  and  you  must 
remember  that  we  not  only  did  not  address  all  aspects  of  life  cycle  costs  but  also  we  did  not  study 
everything  to  the  same  depth.  So  the  results  we  show  at  the  end  of  this  paper  are  very  conservative. 

After  establishing  and  zero  basing  the  baseline  production  configuration,  the  air-to-air  superiority 
production  baseline  was  established.  Sixty-three  (63)  trade  studies  were  defined  that  offered  the  potential 
to  reduce  the  total  ownership  cost  and/or  to  provide  essential  2  F‘ Century  aircraft  system  capability.  The 
63  trade  studies  and  numerous  S&T  program  opportunities  resulted  from  numerous,  joint  brainstorming 
sessions  with  numerous  technology  experts.  Eollowing  an  iterative  process  of  analyses  and  review,  the 
findings  of  47  trade  studies  were  approved  for  the  study  aircraft.  Another  6  were  selected  as  options  for 
future  consideration  (Fig  6),  and  the  remaining  1 1  were  not  approved.  The  production  baseline  modified 
by  the  47  approved  trade  studies  is  the  final  configuration  for  the  study.  This  configuration  was  used  for 
O&S  and  acquisition  cost  comparisons  with  the  baseline  configuration. 
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We  will  now  show  a  few  examples  of  the  results  of  the  trade  studies. 

Design  /  Manufacturing  Processes 

As  part  of  the  study,  a  new,  robust  aircraft  design  and  assembly  process  provide  a  flexible,  most  cost 
effective  process  for  building,  modifying,  supporting,  and  maintaining  the  study  aircraft  over  its  20  year 
life  cycle.  (Fig  7) 

The  robust,  flexible,  design  and  assembly  process  to  be  utilized  for  the  study  aircraft  combines  three- 
dimensional  computer  aided  engineering/re-engineering  of  the  current  design  coupled  with  selected 
applications  of  Design  for  Manufacture  and  Assembly  (DFMA).  DFMA  adds  to  the  3D  computer  aided 
design  tools,  the  introduction  of  more  durable  materials,  improved  designs,  automated  manufacturing 
processes,  and  affordable  tooling.  During  the  Phase  I  Study  in-depth  technical  and  cost  analyses  of  the 
application  of  these  modern  methodologies  to  the  current  production  baseline  design  were  accomplished. 
The  results  of  these  analyses  determined  that  3D  computer  re-engineering  would  be  applied  to  all  areas  of 
the  design.  DFMA  techniques  would  be  used  for  a  redesign  of  the  forward  fuselage,  the  wings,  and 
selectively  applied  in  the  empenage  and  center  fuselage  areas  of  the  fighter.  The  most  direct  affect  of  these 
new  processes  is  a  large  reduction  in  fabrication  and  assembly  hours  and  the  corresponding  cost  savings. 

A  major  benefit  of  the  computer-based  design  is  the  flexibility  to  manufacture  major  aircraft  structure  at  the 
most  cost  effective  location,  and  then  be  able  to  mate  the  structural  sections  from  the  various  locations  with 
minimum  design  refinements.  Thus,  3D  re-engineering  combines  improved  design  and  assembly  processes 
with  the  lowest  cost  manufacturer. 

In  addition  to  the  above  benefits,  several  avionics  and  subsystem  upgrades  can  be  directly  incorporated  into 
the  3D  re-engineering  and  DFMA  design  processes.  This  inclusion  of  the  avionics/subsystem  upgrades  can 
significantly  reduce  the  aircraft  (non-recurring)  costs  of  implementing  lower  cost  avionics/subsystem 
enhancements.  The  computer  basis  of  the  design  will  continue  to  make  future  growth  driven  upgrades 
more  efficient,  and  have  a  positive  impact  on  maintenance  training  and  line  maintainer  efficiency.  It  also 
couples  with  the  use  of  electronic  technical  orders. 

An  example  of  the  benefit  of  this  technology  on  parts  count  and  assembly  is  shown  on  figures  8  &  9  but  the 
problem  of  incorporating  this  technology  in  cost  estimating  is  also  shown.  When  the  cost  estimating  was 
accomplished  using  historical  methods  for  115  units,  the  estimated  cost  of  these  assemblies  were  predicted 
to  increase  even  though  there  was  approximately  a  50%  parts  count  reduction.  This  is  because  the  models 
are  weight  based  and  we  allowed  the  weight  to  increase  if  it  simplified  a  fabrication  or  build  problem.  The 
delta’s  in  the  cost  estimates  highlight  the  uncertainty  in  the  estimating  techniques  even  for  simple  structure. 


Effect  on  Maintainability 

A  significant  part  of  achieving  RTOC  savings  is  improved  Reliability  and  Maintainability  (Fig  10).  The 
study  aircraft  configuration  provides  significant  improvement  in  R&M  versus  the  baseline.  These 
improvements  are  across  all  major  subsystems  within  the  aircraft.  This  is  very  significant.  Not  only  does 
this  reduce  the  overall  unscheduled  maintenance  man-hours  of  the  aircraft  by  approximately  70%,  but  by 
balancing  the  improvement  across  all  areas  ensures  an  overall  system  impact.  The  steeper  slope 
maintenance  man-hours  for  the  different  subsystems  indicates  the  criticality  of  certain  key  “bad  actors”  to 
overall  weapon  system  performance.  If  not  addressed  for  any  reason,  a  single  subsystem  can  drive  the  total 
aircraft  maintenance  requirements.  Figure  1 1  shows  what  the  maintainer  of  the  near  future  could  be.  With 
electronic  maintenance  instructions  interwoven  with  3  dimensional  solid  models,  the  maintainer  has  not 
only  everything  he  needs  to  accomplish  the  required  maintenance  action,  but  also  to  train  in  virtual  reality 
while  the  aircraft  is  returning  to  base  with  the  known  maintenance  squawks. 

Coupled  with  the  improved  R&M,  the  aircraft  configuration  possesses  features  that  will  provide  significant 
assistance  to  the  aircraft  maintainer.  The  Organizational  to  Original  Equipment  Manufacturer  (O-to-OEM) 
maintenance  concept  can  greatly  simplify  flight  maintenance  by  providing  a  “remove  and  replace” 
approach.  The  O-to-OEM  approach  is  facilitated  by  highly  reliable  equipment  with  improved  diagnostics. 
The  Vehicle  Management  System  is  a  key  example  of  the  improved  diagnostics  available  within  the  2F‘ 
Century  configuration.  Einally,  the  use  of  new  generation  of  electronic  technical  orders  (Interactive 
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Electronic  Technical  Manuals  -  lETMs)  will  provide  more  available,  more  explicit  support  of  the  flight  line 
maintainer  both  at  home  and  when  deployed.  The  improved  R&M,  a  balanced  O&S  design,  elimination  of 
PDM,  and  next  generation  aids  for  the  maintainer  combine  to  have  a  significant  impact  on  Total  Cost  of 
Ownership.  This  combination  also  reduces  the  impact  of  lower  maintainer  experience  levels  currently 
experienced  in  the  fleet. 

Deployment  Footprint 

We  did  a  small  study  on  deployment  footprint  and  got  significant  results  that  will  cause  us  to  look  at  this 
area  in  the  next  phase.  By  adding  an  APU  to  the  configuration,  we  were  able  to  reduce  the  deployment 
requirements  for  airlift.  Eigure  12  shows  the  reduction  in  airlift  requirements  by  adding  an  APU  to  the 
airplane  so  it  could  be  maintained  away  from  main  operating  bases  with  a  reduction  in  ground  support 
equipment 

Final  Results 


Prom  the  study,  we  were  able  to  potentially  reduce  the  acquisition  costs  by  40-60%;  the  O&S  costs  by  40- 
70%;  and  direct  personnel  support  by  25-55%.  Remember  that  with  these  results,  we  did  not  address  the 
total  Life  Cycle  Costs  so  there  are  more  opportunities  for  cost  reduction  than  what  is  presented  in  this 
paper.  Along  the  way,  we  started  talking  about  an  aircraft  that  has  a  scheduled  inspection  cycle  of  100,000 
miles  or  5  years.  Although  starting  as  a  joke,  it  did  start  people  thinking  “out  of  the  box”  and  we  have  new 
ideas  to  explore  for  future  reductions  in  cost  of  ownership. 

The  study  showed  the  necessity  of  obtaining  new  certified  cost  metrics  so  that  everyone  understands  the 
impact  of  technology  on  historical  cost  estimating  relationships.  Also  we  think  this  process  will 
revolutionize  the  aircraft  industry  and  the  Air  Porces  of  the  world. 

Summary 

The  RTOC  configuration  achieved  all  the  objectives  of  the  study,  and  met  a  large  majority  of  the  USAP 
defined  future  requirements.  The  integration  of  new  technology,  flexible  acquisition  systems,  and  advance 
processes  can  reduce  the  cost  of  ownership  of  all  aerospace  systems.  But  these  technologies/  processes  can 
only  be  implemented  after  the  data  is  gathered  so  that  the  business  cases  can  be  made  to  use  the 
technologies. 


AFFORDABILITY  ISSUES 

Most  of  Today’s  Inventory  are  Legacy  Weapon  Systems 
Today:  41%  >24  Years  Old 
In  2005;  75%  >20  Years  Old 
Sustainment  Cost  of  Legacy  Systems  Continue  to  Increase 
Limited  Funds  Exist  for  New  Technology  Insertion 

Business  Cases  for  New  Technology  Insertion  and  Processes  Rely  on  Accurate  Costs  / 
Savings  Databases 

Low  Credibiiity  for  Savings  that  Result  from  New  Technology 

-  “Bits  &  Pieces”  Approach  Not  Cost  Efficient 

-  Little  Data  Exists  to  Create  Cost  Models  Deltas 

-  Weight  Based  or  Part  Count  ModeisNot  Always  Valid 

-  CAIG’s  Not  Accepting  Technology  Cost  Benefits 

-  Future  Weapon  Systems  Incorporating  New  Technology  May  Not 
Benefit 

Inability  of  Current  System  to  Estimate  Cost/Savings  of 
New  Technology/  Process  Improvements 


Figure  1 


Increasing  Cost 
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Figure  2 


Virtual  Manufacturing 

Reduces  Rework  and  Improves  Learning 


Figure  3 
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Technology  Maturity  Levels 


•System  Test,  Flight 
and  Operations 


•System/Sub  system 
Development _ 


•Technology  Demonstr^on 


•Technology  Development 


•Research  to  Prove  Feasibility 


9  Actual  System  “Flight  Proven”  Through 
Successful  Mission  Operations 
8  Actual  System  Completed  aid  “Flight 
Qualified”  Through  Test  and  Demonstration 
7  System  Prototype  Demonstration  in  an 
Opa'ational  Environment 

6  System/Subsystem  Model  or  Prototype 
Demonstr^on  in  a  Relevant  Environment 

5  Componentand/or  Breadboard 
Validation  in  Relevant  Environmait 
4  Componentand/or  Breadboard 
Validation  in  Laboratory  Environment 
3  Analytical  and  Experimental  Critical  Function 
and/or  Characteristic  Proof-of-Concept 


•Basic  Technology  Research 


2  Technology  Conceit  aid/or  Application 
Formulated 

1  Basic  Principles  Observed  and  Reported 


Figure  4 


LIFE  CYCLE  COST 
ELEMENTS 


Flyavra^ 

Management 

Hardware  (Fab  &  Assembly) 
Hardware  (Purchased) 
Software 

Nonrecurring  Startup 
Warranty  Maintenance _ 


plus 

Support  Equipment 
Training  Equipment 
Tech  Data 
Publications 
Factory  Training 


Weapon  System 


plus 

Initial  Spares 


Procurement 


Program  Acquisition 


Facility 


plus 


COgerations  and  Supp^ 

Dispoial 


Life  Cycle  Cost 


Figure  5 
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21**  Century  RTOC 

Trade  Studies 

AVIONICS  MODERNIZATION 

NEW  PROCESSES  /  TECHNIQUES 

•  Modern  EW  System 

•  Lean  Certification 

•  Advanced  Programmable  Armament  Control  Set 

•  Open  System/Commercial  Technology 

•Joint  Helmet  Mounted  Cueing  System 

•  Lean  Maintenance 

•  Improved  Communication  System 

•  End-to-End  3-D  Electronic  Modeling 

*  Advance  Display  Core  Processor 

*  Manufacturing  Fabrication  /  Assembly 

•  Object  Oriented  Software 

•  Commercial  Business  Practices 

•APG-63(V)1  Radar 

•  ESA  Structural  Provisions 

•  Modern  Open  System  LRU’s 

REDUCED  O&S  COST 

*  Liquid  Crystal  Displays 

*  Night  Vision  Cockpit 

•Two  Level  Maintenance 

*  Fiahter  Data  Link 

*  High  Reliability  Avionics 

•  Hiah  Sneed  Bus  ADVANCED  WEAPON  CAPABILITY  •  improved  Diagnostics 

•  Multi-Role 

•  Eliminate  Structural  PDM 

•  Increased  -1760  Caoabilitv 

•  Enables  Portable  Maintainer 

•High  Off-Bore  Sight  Missile  •  Reduced  Specialty  Codes 

•  Pn  Bomb  Rack  Option 

SUBSYSTEM  IMPROVEMENTS 

STRUCTURAL  ENHANCEMENTS 

•  Vehicle  Management  System  with: 

•  New  Wi  ng  &  Verti  cal  T ail 

♦  Digital  Fly-By -Wire 

*  Grid-Lock  Control  Surfaces 

•  Throttle-By-Wire 

•  Common  Engine  Bay 

•  Remote  Interface  Units 

*  Eliminate  Exotic  Materials 

•  Modern  Direct  Drive  Actuators 

•  Reduced  Part  Count 

•  Improved  Reliability  Engines 

•  Auxiliary  Power  Unit 

Figure  6 


3D  Re-Engineering  Process 

“3D  RE-ENGINEERING”  Applies  Advanced  Computer  Aided  Design 
Tools  to  an  Existing  Design  to  Improve  Part  Fit-Up  and  Tooling  Use 
~>  Reduces  Assembly  Labor  and  Cycle  Time 

I  I  Design  _  _ 


I  2D  Drav/ings  j 

I  Shop  Visits 

Tooling 


•  Manufacturing  Cost  Reduction 

•  Low  Risk  -  Requires  No  Testing  or 
Changes  to  O&S  Infrastructure 

•  Digital  Data  Can  be  Used  to  Reduce] 
Fab,  Future  Mods  and  O&S  Costs 


Correct  Design  &Tooling 
Nominal  Geometry 


•  Dimensions  & 
Tolerances 
« Minor  Tooting 
Features 
•Assy  Sequence 


•  Digital,  Graphic 
Format 


Determine  Cpk’s 
Update  Capability  Data 


Figure  7 
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Preliminary  Center  Fuseiage  Re-Design 

Recurring  Cost  Benefits 

Baseline  Configuration  - 

-Approximately  2,500  Structural  Parts  (not  including  clips/brackets) 

-  Majority  of  Parts  are  Formed  Aluminum  Sheet  and  Extrusions 
-Weight  approximately  5,000  lb 

-  Simple  Fabrication 
-Complex  Assembly 

Re-Design  Configuration  - 

-Approximately  1,100  Structural  Parts  (not  including  clips/brackets) 

-  Primarily  Composite  Skins/Ducts  and  Aluminum  HSM  Substructure 
-Weight  approximately  5,400  lb  (More  Composites,  Less  Thickness  Tailoring) 
-Automated  Fabrication 

-  Simpler  Assembly 

40-50%  Reduction  Structural  Parts 
20-30%  Fastener  Count  Reduction 

10-15%  Increase  In  Cost  Per  Unit 


Figure  8 


STRUCTURES  TRADE  STUDIES 

Design  for  Manufacture  &  Assembly  (DFMA) 

DFMA  Combines  Advanced  Computer  Aided  Design  Toois,  Durabie  Materiais, 
improved  Designs,  Automated  Manufacturing  Processes,  and  Affordable 
Tooling  in  a  New  Configuration  — >  Reduces  Labor,  Cycle  Time,  &  O&S  Costs 


Skins  - 1  Piece  Composite 
Skins,  No  Stiffeners 


Inb’d  Substructure  -  No  Major 
Changes  to  Carry-Thru, 
Simplify  Machininqs _ 


Outb’d  Substructure  - 
Channel  Sections  Only, 
Increase  Titanium  Usage 


TE  Ass’y  -  Eliminate  40% 
of  the  Ribs,  Simplify  Sections, 
and  Increase  Titanium  Usage 


LE  Ass’y  -  Eliminate  40% 
of  the  Ribs  and  100% 
Chem  Mill  on  Skins 


Proposed  Wing  Re-Design 
Historic  CER’s;  25-10%  increased  Cost 
NewCER’s:  40-60%  Reduction  in  Cost 


Figure  9 
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Balanced  O&S  Design 


TOP  15  IN  MAINTENANCE  MAN-HOURS 

Improves  System  R&M. . . . 

•  Across  the  Board  Improvement  in 
R&M 

•  Reduces  R&M  Differences  Between 
“Bad  Actors”  and  Other  Systems 

•  Eliminates  Need  for  RDM 


(ORGANIZATIONAL  AND  INTERNEDIATT) 


TOP  15  IN  MAINTENANCE  MAN-HOURS 
(ORGANIZATIONAL  AND  INTERNEDIATE) 


•  O  to  OEM  Maintenance 
■  Improved  Diagnostics 

•  Electronic  Tech  Orders 

•  Reduced  Number  of  AFSCs 


Figure  10 


PORTABLE  MAINTENANCE 
Incorporates  Open  Arehitecture 


Software  and  Web  Based 
Technologies 
JAVA  Script 
Visual  Basic  Script 
CGI  Script 
Active  Server  Pages 
Web  Server 
Dynamic  HTML 
SQL 

Web  browser 


Portable 
Computer 
Technologies 


Head  Mounted/ 
Heads  Up 
Display 
Technology 


Voice  Command 
and  Streaming 
Audio  Software 


Portable  Battery 
Li-ion 


Wireless  LAN 


Figure  11 
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Figure  12 
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Future  Initiatives  for  Obsolescence 
Mitigation  Strategies 
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Abstract  The  accelerating  pace  of  technology 
change  requires  new  approaches  to  the  design, 
manufacture  and  through  life  support  of  military 
and  long  life  cycle  commercial  platforms  to 
minimise  the  effects  of  short-term  technology 
obsolescence.  The  purpose  of  this  paper  is  to 
describe  medium  and  long-term  strategies  for  the 
mitigation  of  obsolescence  currently  being 
considered  in  the  UK.  All  complex  military 
equipments  are  at  risk  from  the  effects  of 
unmanaged  technology  obsolescence  before  and 
after  they  enter  service.  A  systems  engineering 
approach  is  described  for  the  evolution  of 
strategies  that  would  involve  co-operation 
between  users  and  manufacturers  to  produce 
affordable  through  life  solutions 

Introduction  Technology  obsolescence  in 
military  and  commercial  long  life  cycle  systems  is 
now  occurring  at  a  far  faster  rate  that  at  any  other 
time  in  contemporary  history.  The  gradual  demise 
of  military  qualified  parts  and  the  availability  of 
state  of  the  practice  Commercial  off  the  Shelf 
(COTS)  technology  requires  smart  technology 
obsolescence  management  and  technology 
insertion  techniques  to  achieve  and  maintain 
military  and  commercial  advantage. 

The  average  rate  of  change  of  technology  for 
semiconductor-based  components  available  to 
meet  future  military  requirements  is  expected  to 
continue  to  decrease  from  its  present  three  year 
term  to  less  than  two  years  by  2005.  Components, 
which  are  presently  being  designed  into  new 
systems,  have  a  high  probability  of  being  obsolete 
when  the  equipment  enters  service  and 
unavailable  when  subsequently  required. 


Today  the  major  thrust  of  electronics  technology 
development  is  almost  entirely  dominated  by  high 
volume  commercial  requirements  to  satisfy  the 
rapidly  expanding  market  opportunities  for  video 
games,  personal  computers,  mobile 
communications  systems  and  new  developments 
in  the  automotive  industry.  The  computer  and 
communications  industry  alone  accounts  for  more 
than  70%  of  the  market  share.  Although  the 
military  requirement  for  semiconductor  products 
is  now  far  greater  than  it  has  ever  been,  its  actual 
share  of  the  market  has  dropped  from  greater  than 
90%  in  the  1970’ s  to  less  than  0.5%  today.  The 
projected  growth  and  viability  of  these  markets  is 
such  that  satisfying  the  military  requirement  takes 
a  low  priority  with  the  major  semiconductor 
manufacturers  many  of  whom  have  now  withdraw 
completely  from  this  market  sector. 

The  military  is  increasingly  not  the  instigator  of 
the  design  process  for  products  that  it  requires  in 
weapons  platforms  and  has  to  react  and  respond  to 
the  imperatives  that  drive  the  process  of  change  in 
the  commercial  market  place. 

The  introduction  of  COTS  components  into 
military  systems  enables  new  technology  to  be 
incorporated  quickly  and  at  a  fraction  of  the  cost 
of  traditional  MOD  funded  research.  These 
benefits  are  however  accompanied  by  concerns  of 
inadequate  environmental  robustness,  the  lack  of 
traditional  military  screening  processes  and  short¬ 
term  commercial  technology  life  cycles. 
Commercial  product  life  cycles  in  turn  create 
problems  of  accelerating  functional  and 
component  obsolescence,  resulting  in  the 
requirement  to  deliver  frequent  technology 
upgrades  into  systems  that  have  not  been  designed 


Paper  presented  at  the  RTO  SCI  Symposium  on  “Strategies  to  Mitigate  Obsolescence  in  Defense  Systems 
Using  Commercial  Components” ,  held  in  Budapest,  Hungary,  23-25  October  2000,  and  published  in  RTO  MP-072. 
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to  accommodate  new  technology  insertion  on  a 
regular  basis. 

Whilst  semiconductor  technology  obsolescence  is 
a  cause  for  long-term  concern  in  the  support  of 
electronic  components,  other  areas  of  technology 
obsolescence  ranging  from  mechanical 
components  to  software  are  beginning  to  impact 
cost  and  operational  through  life  support  issues. 
Many  of  these  technologies  are  inextricably 
linked  within  an  equipment  requiring  a  systems 
engineering  approach  to  obsolescence 
management  and  not  the  conventional 
components  based  discrete  technology  solutions. 

Research  in  DERA  is  showing  that  in  future 
systems  there  is  a  growing  interdependency 
between  obsolescence  solutions,  reliability 
concerns  and  COTS  insertion.  Future 
obsolescence  solutions  have  to  ensure  that  all 
these  areas  of  technology  are  addressed  if  the  goal 
of  effective  low  cost  through  life  support  is  to  be 
met. 

The  Present  Management  of  Obsolescence: 

Within  many  organisations  obsolescence 
management,  if  it  is  done  at  all,  is  done  reactively. 
It  is  very  rarely  part  of  the  design,  development 
and  sustainment  policy  and  certainly  the  costs  of 
reactive  obsolescence  management  are  generally 
unknown. 

Within  the  military  and  most  defence  contractors 
obsolescence  problems  are  generally  solved 
serially  within  projects,  on  an  ad  hoc  basis,  with 
no  lessons  learnt  feedback  to  other  parts  of  the 
system  or  across  the  organisation.  This  situation 
arises  as  a  direct  result  of  the  reactive  nature  of 
obsolescence  management  with  the  problems 
mainly  being  discovered  during  repair  in  response 
to  equipment  failure.  At  the  time  the  parts  status  is 
discovered  it  may  be  to  late  for  last  time  buys  and 
the  part  is  no  longer  available.  Considerable  cost 
may  then  be  involved  in  finding  an  equivalent  part 
or  in  the  worst  case  having  to  redesign  the  system. 
The  fact  that  an  equivalent  part  can  be  found  may 
only  provide  a  short-term  solution  since  the  total 
parts  obsolescence  status  of  other  components  on 
the  board  or  other  boards  within  the  equipment  is 
not  known. 

The  DERA  approach  takes  a  proactive  systems 
engineering  view  of  obsolescence  management 
encouraging  a  “no  suprises”  culture  that  provides 


time  to  devise  affordable  solutions  which  can  then 
be  implemented  across  multiple  platforms. 

Obsolescence  Management  Tools:  The  DERA 
obsolescence  management  tools  allow  the 
customer  to  minimise  future  obsolescence  at  the 
equipment  development  phase,  determine  the 
obsolescence  status  before  procurement,  plan  the 
most  cost  effective  timescales  for  in  service 
technology  updates  and  manage  obsolescence  in 
legacy  equipments  to  extend  their  service  life. 

The  tools  consist  of  a  relational  database,  EPIC 
2000,  and  ITOM  an  equipment  configuration  tool 
that  allows  the  total  parts  distribution  to  be 
viewed  at  any  level  of  indenture  in  a  system. 

The  Electronics  Parts  Information  Centre  (EPIC 
2000)  contains  information  on  over  1.2  million 
semiconductor  devices  consisting  of: 

•  Original  Component  Manufacturer 

•  Full  Parametric  Information 

•  Availability  Information 

•  International  Parts  Reference 
Numbers 

•  Possible  Equivalents 

The  Integrated  Technology  Obsolescence 
Manager  (ITOM)  is  a  configuration  management 
tool  that  can  identify  all  the  hierarchical  levels  in 
a  military  platform  and  populate  them  with  data 
imported  from  the  EPIC  2000  database.  The 
functionality  of  ITOM  is  such  that  it  is  possible  to 
obtain  obsolescence  information  at  discrete 
device,  board,  assembly,  cabinet,  LRU,  system  or 
platform  level.  It  also  has  the  ability  to  address 
any  combination  of  multiple  platforms  and  build 
standards. 

The  operation  of  the  ITOM  tool  is  via  user 
friendly  screens  that  follow  logical  paths  to 
determine  the  current  and  projected  availability  of 
components  at  any  level  of  indenture  in  a  system 
or  system  of  systems. 

An  availability  code  on  each  component  indicates 
the  timescales  to  obsolescence  up  to  a  maximum 
predicted  value  of  8  years.  The  predicted 
obsolescence  timescales  are  derived  from  life 
cycle  algorithms,  which  are  continuously 
reviewed  against  expert  opinion  and  knowledge  of 
technology  trends. 
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Methodologies  The  EPIC2000  database  can  be 
used  as  a  stand  alone  tool  that  can  be  addressed  by 
the  user  with  single  or  multiple  enquiries.  This 
approach  is  however  not  recommended  since  it 
does  not  provide  an  overall  view  of  the  total 
obsolescence  problem  and  can  lead  to  increased 
cost  of  ownership  with  time. 

For  Military  and  Defence  Contractor 
requirements,  obsolescence  is  generally  addressed 
on  a  project  by  project  basis.  Using  the  ITOM  tool 
the  system  configuration  is  populated  from 
customer  furnished  parts  lists  and  then  managed, 
on  behalf  of  the  customer  through  out  the 
equipment  life  cycle.  The  customer  is  provided 
with  regular  obsolescence  health  check  reports 
and  priority  alerts  to  inform  of  unexpected 
component  non-availability.  At  any  time  the 
customer  can  receive  suggested  equivalents  or 
alternatives  to  obsolescent  parts  to  enable 
decisions  on  the  most  cost  effective  solutions  to 
be  reached. 

The  Evolution  of  Obsolescence  Management: 

At  present  in  most  legacy  systems  military  grade 
qualified  parts  are  still  the  norm.  Obsolescence  is 
managed  via  a  combination  of  available  military 
equivalents  or  best  case  commercial  parts.  Many 
of  these  systems  however  still  have  predicted 
future  in-service  lives  in  excess  of  30  years  or 
more  with  the  result  that  the  management  of 
obsolescence  at  component  level  will  become 
increasingly  more  difficult  as  the  original  military 
and  equivalent  commercial  discrete  devices 
become  obsolete. 

The  accelerating  rate  of  commercial  technology 
and  the  proliferation  of  short  lifetime  COTS 
components  in  military  systems  will  inevitably 
have  an  effect  on  the  way  technology 
obsolescence  management  evolves.  Conventional 
component  level  obsolescence  management  tools 
will  themselves  become  obsolete  as  new 
innovative  semiconductor  packaging  and  board 
level  technologies  move  the  lowest  levels  of 
system  integration  from  discrete  components  to 
integrated  board  level  assemblies. 

Before  this  point  is  reached  it  is  possible  that 
functional  obsolescence  will  demand  a  technology 
insertion  which  will  increasingly  be  at  board  or 
subsystem  level.  It  is  most  likely  that  the  board 
level  insertion  will  be  a  COTS  component  or  a 
custom  design  containing  COTS  components. 


The  evolution  of  high  density  packaging 
techniques  [1]  for  IC  products  is  mirrored  by  new 
developments  in  board  level  technology  that  can 
take  maximum  advantage  of  Direct  Chip  Attach 
(DCA),  Flip-Chip,  Multi  Chip  Modules  (MCM), 
Chip  Scale  Packaging  (CSP)  and  Systems  on  a 
Chip  technologies.  These  technologies  are  not 
designed  to  be  repaired  and  attempts  to  do  so  will 
have  unpredictable  effects  on  reliability.  The 
market  for  these  new  technologies  is  increasing 
very  rapidly  and  future  predictions  show  that  as 
soon  as  2002  they  may  account  for  about  8%  of 
the  total  worldwide  IC  market. 

It  would  seem  probable  therefore  that 
obsolescence  management  will  have  to  be 
delivered  in  a  number  of  parallel  ways  in  time 
scales  determined  by  the  availability  of  discrete 
device  technology  and  the  introduction  of  new 
integrated  board  level  components.  Conventional 
component  level  obsolescence  management  will 
have  a  window  of  opportunity  after  which  the 
emphasis  will  change  from  delivering  parts 
availability  information,  providing  solutions  bases 
on  equivalent  or  alternative  components,  to  that  of 
advising  on  the  time  scales  for  the  most  cost 
effective  new  technology  insertion  at  board  level. 

The  period  of  twenty  years  or  more  that 
characterises  the  evolving  obsolescence 
management  strategies  will  be  one  were 
Military/Industry  partnerships  are  vital  and 
lessons  learnt  are  widely  disseminated  across  the 
stakeholder  base. 

National  Obsolescence  Centre  Concept: 

The  concept  is  based  on  combining  the  resources 
of  DFRA  and  Industry  to  address  present  and 
future  obsolescence  management  on  a  national 
scale  and  leverage  this  holistic  advantage  to 
provide  a  fast  comprehensive  low  cost  service  to 
all  the  stakeholders. 

The  goal  of  the  National  Obsolescence  Centre  is 
to  globally  manage  tri-service  obsolescence 
problems  in  new  and  legacy  equipments  and  play 
an  active  role  in  devising  future  obsolescence 
mitigation  strategies  jointly  with  MOD,  DFRA 
and  Industry. 

At  present  obsolescence  is  managed  with  a 
scattergun  approach  throughout  MOD  and 
industry.  The  cost  penalties  of  this  uncoordinated 
approach  could  eventually  impact  the  defence 
budget  to  the  detriment  of  R&D  and  new  systems 
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procurement.  The  formation  of  a  focussed 
national  obsolescence  centre  would  enable  a 
system  engineering  approach  to  be  adopted  for  the 
global  management  of  obsolescence  over  the  total 
MOD  inventory.  The  single  focus  for  all 
obsolescence  information  holds  the  promise  of 
rapid  response,  economies  of  scale,  and  the 
elimination  of  duplication  across  the  supplier  and 
customer  base. 

The  eventual  requirement  for  the  Centre  would  be 
to  maintain  a  range  of  component  databases,  with 
current  availability  databases  that  would  include: 

•  Semiconductors 

•  Passive  components 

•  Connectors 

•  Cables 

•  Electrical  components 

•  Relays 

•  Batteries 

•  Electro-optical  components 

•  Microwave  components 

•  Mechanical  components 

•  Software 

•  Lessons  Learnt 

The  lessons  learnt  database  is  a  generic  concept 
for  describing  the  repository  of  solutions  for 
obsolescence  problems.  Eor  most  of  the 
component  databases  solutions  such  as 
equivalents,  are  an  integral  part  of  the  individual 
technology  database  structure. 

A  physical  lessons  learnt  database  would  contain 
information  on  custom  solutions  to  electronic  and 
mechanical  problems  including  the  future 
provisioning  of  sole  sourced  devices  such  as 
ASICS.  It  will  address  many  of  the  “learnt  from 
experience  solutions”  to  COTS  procurement  and 
insertion  problems  throughout  the  equipment  life 
cycle. 

Eor  most  major  defence  contractors  a  large 
proportion  of  their  output  is  dependant  on  the 
added  value  provided  by  Small  to  Medium  size 
Enterprises  (SMEs)  who  are  finding  it 
increasingly  difficult  to  carry  the  financial  burden 
of  obsolescence  management.  Whilst  the  initial 
thrust  of  the  National  Obsolescence  Centre  will 
therefore  be  to  provide  an  affordable  obsolescence 
management  service  to  small  and  medium  size 
companies  it  the  capability  to  service  any  level  of 
stakeholder  involvement. 


Total  Inventory  Obsolescence  Management: 

If  the  total  hierarchical  structure  and  component 
population  of  all  MOD  equipments  were  lodged  at 
the  Centre  a  health  check  of  all  equipments  could 
be  performed  on  a  regular  basis  and  the  customer 
informed  of  component  alerts  and  the  timescales 
in  which  they  need  to  be  addressed.  In  this  way 
the  total  costs  of  managing  obsolescence  across 
MOD  would  be  dramatically  reduced  since  there 
would  be  no  suprises  and  adequate  time  would  be 
provided  to  determine  the  optimal  remedial 
actions. 

The  same  service  could  be  provided  for  long  life 
cycle  commercial  platforms  in  the  aerospace,  oil 
and  medical  industries  where  economies  of  scale 
could  significantly  reduce  through  life  costs. 

The  alternative  is  to  continue  the  present  trend 
and  create  a  series  of  unique  solutions  to  a  single 
problem  across  the  total  customer  base  with 
increasingly  large  cost  and  deployment  penalties 
to  the  customer. 

Built  for  Life  Electronics 

A  Research  project  has  started  in  EY  99/00  that 
will  specifically  address  the  development  of  Built 
for  Life  Electronics  based  on  the  principles  of 
Physics  of  Eailure  [2].  Physics  of  Eailure 
technique  have  shown  that  failure  mechanisms  are 
far  from  random  and  it  is  becoming  possible  to 
predict  failure  times  of  electronic  assemblies  with 
a  degree  of  accuracy  that  promises  the  capability 
of  invoking  the  concept  of  a  guaranteed  life.  The 
technologies  for  guaranteed  life  or 
maintenance/failure  free  operating  periods  (M/E- 
EOP’s)  are  currently  being  funded  by  MOD, 
DERA  and  many  of  the  major  defence  contractors 
in  the  US  and  Europe  through  the  CALCE 
initiative  at  the  University  of  Maryland.  The 
DERA  programme  will  investigate  the 
applicability  and  impact  of  these  techniques  at 
system  level  and  the  possible  future  direction  of 
this  type  of  research  within  DERA  and  industry. 

Physics  of  Failure  (PoF):  Physics  of  Failure  is  an 
approach  to  develop  reliable  products  that  uses  the 
knowledge  of  root  cause  failure  mechanisms  to 
prevent  product  failures  in  the  field  by 
incorporating  PoF  at  the  product  design  stage. 

The  PoF  approach  incorporates  reliability  into  the 
design  process  by  establishing  a  scientific  basis 
for  evaluating  new  materials,  structures  and 
electronics  technologies.  An  important  aspect  of 
the  technique  is  the  ability  to  predict  the  time  to 
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failure  of  specific  failure  mechanisms  throughout 
the  system  geometry. 

The  Physics  of  Failure  approach  involves: 

•  Identifying  potential  failure  mechanisms 
including,  chemical,  electrical,  physical, 
mechanical,  structural  or  thermal 

•  Identifying  failure  sites  including  component 
interconnects,  hoard  metallisation,  or  external 
connections 

•  Failure  Modes  including  electrical  shorts, 
opens  or  problems  associated  with  failure 
mechanisms  resulting  in  electrical  deviations 
heyond  specification. 

•  Identifying  failure  mechanism  models  and 
their  input  parameters  including  materials 
characteristic,  relevant  geometry  at  failure 
sites,  manufacturing  defects  and 
environmental  and  operating  loads. 

•  The  provision  of  information  to  determine 
electrical,  thermal  and  mechanical  stress 
margins. 

Physics  of  failure  models  can  he  applied  to 
accelerated  life  testing  of  electronic  components 
to  assess  the  reliability  and  lifetimes  under  normal 
stress  conditions.  As  the  use  of  the  PoF  approach 
increases  this  method  may  become  a  routine 
process  during  the  design  and  evaluation  phase  of 
the  product  lifecycle 

M/F-FOPS:  Physics  of  Failure  techniques  can  be 
used  to  design  a  system  for  maintenance  and 
failure  free  operating  periods.  Maintenance  free 
operating  period  (M-FOP)  is  defined  as  a  period 
of  time  during  which  a  system  is  operational  and 
is  able  to  carry  out  its  required  functions  without 
maintenance  and  without  encountering  failures.  A 
failure  free  operating  period  (F-FOP)  is  defined  as 
a  period  during  which  no  failures  resulting  in  a 
loss  of  system  functionality  occur 

The  M/F-FOPs  approach  is  the  basis  of  the 
concept  of  built  for  life  electronics  when  used  in  a 
defined  operational  envelope. 

When  built  for  life  electronics  is  used  to  describe 
a  disposable  or  throw  away  item  it  could  be 
described  as  an  F-FOP.  A  system  containing 
multiple  built  for  life  units  could  be  an  M-FOP 
which  contains  units  with  known  remaining  life 
and  hence  known  maintenance  schedules. 


Health  Unit  Monitors:  Health  unit  monitors 
(HUMs)  are  required  to  monitor  built  for  life 
equipments  to  ensure  that  excursions  outside  the 
agreed  operational  envelope  are  observed.  New 
DERA  initiated  research  in  the  CALCE 
programme  is  designed  to  enable  the  HUMs  to 
perform  the  dual  function  of  Event  Monitoring 
and  Life-Consumption  monitoring  by  mapping 
event  data  into  damage  accumulation  models  to 
provide  indications  of  remaining  life. 

Open  Systems  [3]:  To  obtain  the  maximum  cost 
and  operational  advantage  from  built  for  life  units 
they  should  be  compatible  with  an  open  systems 
approach  to  equipment  design. 

An  open  system  is  a  system  that  implements 
sufficient  open  specifications  for  interfaces, 
services  and  supporting  formats  to  enable 
properly  engineered  components  to  be  utilised 
across  a  wide  range  of  systems  with  minimum 
change.  The  success  of  open  systems,  in  future 
military  systems,  lies  in  the  choice  of 
commercially  supported  specifications  and 
standards  for  interfaces.  Interface  standards 
generally  have  long  lifetimes,  some  as  long  as  25 
years,  and  can  outlast  any  particular  product, 
vendor  or  technology. 

The  attraction  of  open  systems  is  due  to: 

•  Portability-The  ease  with  which  a  system, 
component,  data  or  software  can  be 
transferred  from  one  hardware  or  software 
environment  to  another. 

•  Interoperability-The  ability  of  two  or  more 
systems  or  components  to  exchange  and  use 
data 

•  Scalability-The  capability  of  hardware  and 
software  to  accommodate  changing  workloads 

•  Vendor  Independence-Products  available  on  a 
commercial  basis  from  multiple  vendors 

•  Supportability-  easy  upgrades  or  technology 
insertion 

An  open  systems  approach  to  future  designs 
promises  to  solve  many  of  today’s  problems  and 
specifically  to  allow  maximum  advantage  to  be 
taken  of  the  availability  of  state  of  the  art  COTS 
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technologies  in  an  incremental  acquisition 
process. 

DoD  as  far  back  as  1994 [4]  recognised  the 
problem  and  issued  a  directive  that  instructs 
programme  managers  to  employ  open  systems  as 
a  design  consideration  in  defence  systems 
engineering. 

Open  systems  provide  an  opportunity  to  achieve 
lower  cost  affordable  designs  which  can  readily 
accommodate  new  technology  insertion  over  the 
whole  life  of  the  system  with  the  additional 
advantage  that  upgrade  technologies  can  be  state 
of  the  practice  technology  from  multiple 
suppliers.  The  approach  also  mitigates  against  the 
risks  of  obsolescence  by  using  commercially 
supported  interface  standards  permitting  upgrades 
and  new  technology  insertion  at  relatively  low 
cost. 

A  Possible  Future:  The  prospect  of  maintenance 
and  failure  free  operating  periods  for  electronic 
components  in  open  architecture  systems 
promises  to  provide  a  neat  low  cost  solution  to  the 
obsolescence  problem  as  well  as  addressing  the 
short  term  technology  upgrade  problems  in 
military  and  commercial  equipments. 

The  incorporation  of  low  cost  life  consumption 
monitors  based  on  highly  integrated 
environmental  sensors  holds  out  the  promise  of 
predicting  in  real  time  the  remaining  life  of 
electronic  assemblies. 

The  advantages  of  no  obsolescence  problems, 
known  reliability  and  seamless  technology 
upgrades  coupled  with  a  faster  development 
timescale,  a  better  product  at  lower  cost  with  a 
fast  time  to  market  will  satisfy  the  requirements  of 
both  military  and  commercial  customers. 

Conclusions:  Proactive  obsolescence 

management  will  require  a  culture  change  in  both 
Military  and  Defence  Contractors.  It  is  not 
difficult  to  see  that  if  obsolescence  was  managed 
on  a  tri-service  basis  considerable  insight  into 
major  problem  areas  and  valuable  lessons  learnt 
could  be  fed  back  into  research,  development  and 
procurement  cycles. 


teamed  jointly  to  form  a  National  Obsolescence 
Centre  that  could  address  obsolescence  on  a 
global  basis  across  the  total  customer  inventory. 
The  concept  of  teaming  offers  many  areas  for  cost 
reduction  within  MOD  and  Defence  Contractors 
whilst  adding  to  the  overall  knowledge  of  the 
participants.  It  would  have  the  added  advantage 
that  work  was  not  duplicated  and  solutions  could 
be  disseminated  to  all  the  participants  across 
multiple  platforms  in  real  time.  Defence 
Contractors  who  also  address  the  commercial 
market  could  gain  possible  commercial  advantage 
by  predicting  reduced  levels  of  through  life 
maintainability. 

It  is  now  possible,  albeit  with  some  difficulty,  to 
manage  semiconductor  component  obsolescence, 
that  is  to  maintain  the  equipment  to  its  originally 
specified  functionality  throughout  its  service  life. 
In  most  cases  however  this  may  not  be  sufficient 
since  the  rapid  acceleration  in  technology 
innovation  will  make  the  original  equipment  itself 
functionality  obsolescent.  A  systems  engineering 
approach  to  obsolescence  management  is  required 
to  determine  the  most  effective  solutions  for 
equipment  modifications,  upgrades  or  new 
technology  insertion  at  any  point  in  the  equipment 
life  cycle. 

The  increasing  use  of  commercial  off  the  shelf 
(COTS)  components  in  military  and  long  life 
cycle  commercial  equipments  will  exacerbate  the 
problems  of  component  obsolescence 
management.  COTS  components  undoubtedly 
save  front  end  costs  through  the  development  and 
procurement  stages  when  compared  to  traditional 
military  components.  They  also  carry  the  risks  of 
technology  development  being  driven  by 
commercial  requirements  rather  than  to  provide 
enhanced  capability  in  a  military  scenario 

The  solutions  to  component  obsolescence, 
commercial  technology  insertion  and  reliability 
are  increasingly  inter  related  as  new  technology 
evolves.  Cost  effective  solutions,  based  on  open 
systems  design,  with  the  availability  of  guaranteed 
life  COTS  components,  must  address  these  areas 
simultaneously  over  a  wide  range  of  technologies 
to  achieve  the  optimum  performance/cost 
benefits. 


Obsolescence  could  be  managed  to  greater 
advantage  if  the  Military  and  Defence  Contractors 
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EPIC  2000 


•  Relational  Database 

•  Data  Currency 

•  Parts  Description 

•  Parts  Equivalence 

•  Obsolescence  Predictions 


What  we  require  is  to 

+  Turn  Reactive  Obsolescence  Management 
+  into  Proactive  Obsolescence  Management 

•  Continuous  real  time  health  checks  of  the  total 
component  count  across  multiple  platforms 
from  multiple  users 

•  Simultaneously  inform  every  user  who  has  a 
problem  the  location  and  extent  of  the  problem 

•  Solve  the  problem  once  only  and  inform  all  the 
owners 
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Department  of  Trade  and  Industry 
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NOC  Component  Databases 


Obsolescence  Management  Evolution 

Qualified  Components  COTS  Components  ^ 


Conventional 

PCBs 


High  Density 
PCBs 


Flip  Chip  MCM 
CSP  DCA 
SoC 


Repairable 

Known  parts 
population 

Parts  Availability 


Faster  parts 
obsolescence 
Component 
configuration  ? 


Non  repairable 

Board  level 
Obsolescence 


Conventional 
Obsolescence  Management 


Board  Level  Obsolescence 
Management  Strategies 
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Physics  of  Failuiro 

A  Probabilistic  Science  Based  Approach 
to  Reliability  Prediction 

•  Identification  of  Failure  Modes,  Mechanisms 
and  Failure  Sites  prior  to  Build 

•  Reliability  Predictions  at  Design  Stage 

•  Virtual  Reliability  and  Qualification 

•  Software  and  data  for  Circuit  Board  and  Device 
Level  Analysis 


Maintenance/Failure  Free  Operating  PeriQdls 

M//F-FQPS 


Maintenance  Free  Operating  Periods  M-FOPs 

A  period  of  time  during  which  a  system  is  able 
to  carry  out  its  required  function 
without  maintenance  activity 
and  without  encountering  failures 


Failure  Free  Operating  Periods  F-FOPS 

A  period  of  time  during  which  no  failures 
resulting  in  a  loss  of  systems  functionality  can  occur 
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Open  Systems 

An  Open  System  is  a  system  that  implements 
sufficient  open  specifications  for  interfaces, 
services  and  supporting 

formats  to  enable  properly  engineered  components  to  be 
utilised  across  a  wide  range  of  systems  with  minimal  change 


Characterised  by 

Commercially  supported  specifications 
and  standards  for  system  interfaces 
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Built  for  Life  Electronics 


What  does  the  user  want  to  know 


Remaining  usefui  iife 


Difference  between  manufacturers  guaranteed  life 
and  that  lost  due  to  wear  out  and  out  of 
specification  excursions 


Built  for  Life  Electronics 


Life  Consumption  Monitoring 
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Leveraging  New  Information  Technologies 
to  Manage  Obsolescence 


Malcolm  Baca 

i2  Technologies  Inc.  (Formerly  TACTech) 
22687  Old  Canal  Road 
Yorba  Linda,  CA  92887,  USA 


In  the  new  economy  of  digital  technology  the  transition  rate  of  component  level 
functionality  is  transitioning  at  an  accelerated  rate  introducing  greater  functional 
complexity.  As  voltage  out  put  scales  downward  and  micron  line  width  design  rules  are 
reduced  there  are  new  generations  of  digital  technology  that  offer  superior  functionality 
that  is  more  reliable,  uses  less  power,  less  real  state,  less  weight  and  smaller  power 
supplies.  The  newer  generations  of  component  technology  are  rapidly  causing  the  older 
generations  of  component  technology  to  become  obsolete  because  the  cost  of  various 
functionality  commodity  groups  are  reduced  with  the  scaled  down  designs.  At  i2  through 
our  global  semiconductor  library  maintenance  we  are  recording  37,000  component 
discontinuance  notifications  on  an  annual  basis.  Within  the  digital  category  a  new 
generation  of  microprocessors  is  being  introduced  every  18  months  and  a  new  generation 
of  memory  type  devices  is  being  introduced  every  9  months  with  speed  and  density 
increases.  This  high  rate  of  technology  transition  is  impacting  the  production  and  spares 
support  to  sustain  weapon  systems  that  require  ten,  twenty,  thirty  or  more  years  of 
operational  support. 

•  To  manage  component  obsolescence  new  information  technologies  are  providing 
specialized  software  tools  and  content  libraries  that  can  be  used  to  reduce  the 
financial  impact  of  semiconductor  obsolescence.  An  example  of  advanced 
obsolescence  information  tooling  that  is  on  the  market  is  offered  by  i2 
Technologies.  Built  into  their  obsolescence  management  software  product  called 
TACTRAC  the  software  provides  life-cycle  projections  that  can  be  used  for 
component  selection  or  assessment  of  existing  designs.  The  i2  component  life 
cycles  can  be  used  to  provide  a  continuous  analysis  of  a  weapon  systems 
production  readiness.  The  same  component  life  cycle  information  can  be  used 
during  the  component  selection  phase  to  screen  out  obsolescence  at  the 
component  level  and  insure  state-of-the-art  components  are  be  selected  for  a  new 
design  or  modernization.  If  software  is  the  motor  the  fuel  for  the  software  is  daily 
updates  on  changing  component  availability.  This  type  of  information  is  supplied 
by  the  i2  global  content  libraries  that  contain  all  semiconductors  made  anywhere 
in  the  world.  As  component  availability  changes,  new  source,  introductions, 
discontinuances,  life  of  buy  notifications,  quality  changes,  packaging  changes  and 
functionality  changes  the  delta  of  change  is  sent  to  i2’s  customers  in  real  time  and 
the  software  tell  the  customer  where  the  parts  are  used  in  their  product 
configurations.  In  addition  to  the  changing  component  “availability  notification” 
the  content  libraries  also  supply  all  form,  fit  and  function  equivalent  parts  thus 
providing  the  user  with  all  replacement  options  if  they  exist.  The  TACTRAC 
capability  offered  by  i2  also  provides  a  means  of  “secured”  data  exchange 
allowing  a  collaborative  operational  environment  to  solve  common  obsolescence 
problems  at  the  component  level.  This  allows  different  divisions  or  program 
offices  to  share  visibility  on  common  component  obsolescence  problems. 

Teaming  a  common  problem  when  evaluating  solution  options  or  leveraging  the 
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collective  purchasing  power  on  a  common  problem  can  save  thousands  of  dollars 
to  a  specific  program.  Fragmenting  the  workload  or  leveraging  the  purchasing 
power  to  make  a  bridge  achieves  such  savings  or  lifetime  buy.  Teaming  common 
problems  will  also  reduce  the  time  to  resolve  the  common  problem.  Clients  using 
i2’s  TACTRAC  obsolescence  service  have  been  able  to  reduce  the  cost  impact  of 
obsolescence  by  15  to  20%.  Such  savings  is  obtained  by  leveraging  collaborative 
operational  environments  on  common  problems,  use  of  life  cycle  projections  and 
daily  notifications  of  changing  component  availability.  By  implementing  this  type 
of  tooling  and  having  access  to  the  content  libraries  this  allows  a  customer  to 
optimize  in  cost  savings  the  following  work  process  flow: 

•  Reduce  time  to  market  for  new  designs  or  modernizations 

•  Component  selection  to  minimize  single  source  situations 

•  Consolidate  technology  baseline  within  an  enterprise  or  program 

•  Reduction  of  imbedded  obsolescence  using  life  cycle  projections 

•  Timely  technology  insertion  and  planning  for  modernization  priorities 

•  Collaboration  on  common  component  obsolescence  problems 

Studies  by  the  US  Department  of  Defense  have  shown  that  70%  of  weapon  system 
expenditures  to  support  a  weapon  system  are  made  in  the  after  market  years.  Proper 
implementation  of  modern  information  services  by  equipment  contractors  and  military 
program  offices  could  reduce  weapon  system  “cost  of  ownership”  by  15  to  20%. 

Reacting  to  individual  component  obsolescence  problems  on  a  situational  basis  can 
become  cost  prohibitive.  Especially  to  programs  that  are  aged  or  are  past  their  mature 
funding  years.  To  properly  utilize  the  newer  information  technologies  will  require  a 
cultural  change  within  the  suppliers  that  build  weapon  systems.  In  the  new  economy 
common  problems  can  be  teamed  protecting  the  security  of  each  company  that  is 
participating  in  the  “teaming”  effort. 
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Abstract 


A  combination  of  2D  barcode  with  digital  signature  and  normal  text  with  polygonal  watermark  is 
proposed.  Against  synchronisation  attacks  the  watermark  reference  points  are  also  included  in  the  2D 
barcode  and  secured  by  a  digital  signature,  whilst  the  2D  barcode  block(s)  are  embedded  in  the  text. 

Keywords  :  2D  barcodes,  robust  digital  watermarks,  digital  signature,  copy-management,  access  control 


1.  Security  of  documents 

Security  of  documents  is  a  general  user  requirement.  During  their  lifecycle  documents  nowadays 
are  born  as  electronic  digital  originals  and  printed  only  later.  Copies  of  documents  are  transformations 
converting  the  same  content  either  onto  digital  or  analogue  form.  One  factor  of  the  security  is  the 
confidentiality  of  the  document  content.  In  this  paper  the  confidentiality  of  a  document  content  printed 
onto  normal  papersheet  pages  is  in  the  focus.  Let’s  assume  that  such  a  confidential  system  is  going  to  be 
developed. 

A  basic  system  funtion  ;  Confidentiality 
Basic  assumptions  : 

It  is  a  general  human  habit,  and  so  an  implicit  user  requirement,  that  every  important  document 
is  going  to  be  printed. 

Executives  dislike  watching  a  monitor  screen,  when  reading  over  lengthy  materials. 

Our  hypothesis  is  that  this  is  thrue  for  confidential/secret  materials  as  well,  so  it  is  a 
requirement  to  protect  confidentiality/secrecy  of  printed  documents  by  means  of  copy 
management  and  logical  access  control  methods. 

System  functions : 

Copy  management 
Logical  access  control 


Techniques  applicable  : 

Encryption  systems 
Steganography/digital  watermarking 
Access  control  systems 

Access  control ;  An  access  control  system  resist  unauthorized  access  to  the  data 

Encryption  :  Encryption  resist  unauthorized  access  to  the  content  of  a  document. 
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Steganography  :  Hiding/embedding  the  secret  information  beyond  a  cover  text  -  that  is  steganograpy. 

But  unlike  encryption,  steganograpy  in  itself  does  not  resist  access  to  the  data  and  it  is 
effective  until  the  detecting  of  the  hidden  communication. 

Problems  :  Used  in  point-to-point  communication  the  information  channel  can  be  subject  of 
various  hostile  attacks  (jitter  attack,  etc.)  aiming  to  fool  the  receiver/detector  by  either  impairing  or 
diminishing  or  removing  the  secret  message. 

After  a  successful  hostile  attack  the  hidden  message  cannot  be  recovered.  As  to  paper  media  attacks  these 
are  usually  detection-disabling  or  desynchronization  geometric  data  manipulations. 

2.  Technical  steganography  approaches 


Various  techniques  of  technical  steganography  can  be  applied  as  well : 

Even  if  the  document  content  is  encrypted,  spread  spectrum  modulation,  scattering 
make  difficult  to  detect  or  jam  transmission.  Camouflage,  special  inks,  materials, 
masking  algorithms  are  widely  in  use  as  follows  : 

Blind  colour  approach 

A  blind  colour  is  „invisible”  for  a  copier/scanner/video/camera/etc.  equipment. 

Assumptions  :  An  original  document  is  printed  by  means  of  a  colour  printer,  and 

the  really  confidential/secret  paragraphs,  details,  or  data  of  the  document  are  to  be 
printed  by  a  blind  colour  (red,  orange,  etc.),  and 

the  rest  of  the  confidential/secret  document  is  to  be  printed  by  a  non-blind  colour. 

Under  the  above  assumptions  the  confidentiality  of  a  photocopied/scanned/photod  document  -  although 
copied  -  will  be  not  corrupted  indeed,  because  the  confidential  details  are  not  on  the  copy. 

Problems  :  Although  a  certain  colour  can  be  blind  only  for  a  subset  of  photocopier/scanner  models, 

but  not  for  all  models. 

Even  with  carefully  selected  photocopier  models  in  office,  original  pages  of  confidential 
content  can  be  fetched  and  photocopied/scanned  outside  by  other  models. 

Video/photocamera,  etc.  can  also  smuggled  in  for  copying  the  whole  material. 

Special  copysafe  papers  are  expensive  and  although  having  been  copied  on  one  model 
onto  a  copysafe  special  page  the  copy  of  the  text  is  really  unreadable,  but  having  been  copied  on 
other  colour  copier  models,  the  output  can  be  a  perfectly  readable  text. 

Chemical  reaction  (heat  or  light  effects)  in  the  copier 

Assumptions  :  The  really  confidential/secret  paragraphs,  details,  or  data  of  the  document  are  to  be 
printed  by  a  special  ink,  and 

in  the  printer  there  is  no  heat-effect  when  printing  the  original  page,  and 
the  background  colour  of  the  text  is  painted  by  a  special  ink  (or  the  text  on  the  page  is 
printed  by  a  special  ink),  wich  will  become  of  the  same  colour  of  the  background,  and 
in  the  copier  there  is  a  heat-effect  over  a  threshold  temperature  (or  light  effect),  and 

when  making  copies,  only  that  copier  is  in  use  (heat-effect  cannot  be  avoided. 

Under  the  above  assumptions  the  confidentiality  of  a  photocopied/scanned/photod  document  -  although 
copied  -  will  be  not  corrupted  indeed,  because  the  confidential  details  are  not  on  the  copy. 

Problems  :  There  are  too  many  underlying  assumptions.  In  practice  these  prerequisits  are  difficult 

and  in  large  organisations  rather  expensive  to  meet. 

Conclusion  :  If  we  want  to  avoid  risky  as  well  as  expensive  proposals,  we  had  better  to  find  a  commercial 
solution,  perhaps  a  combination  of  normal  paper  and  commercial  ink  and  diverse 
printing  equipment  already  existing  in  the  environment.  An  integration  of  some 
carefully  selected  off-from  the  self  commercial  technologies  will  do  a  lot  of  good  to  the 
system. 
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3.  Digital  watermarking  approaches 

System  subfunction ;  Fingerprinting 

Copies  of  digital  documents  are  indistinguishable  from  the  original.  Fingerprinting  (hidden  serial 

numbering)  makes  them  distinguishable,  which  may  become  important  in  case  of  tracing  for 
attackers.  A  hidden  unique  marking  of  each  copy  of  a  document  makes  distinguishable  the 
original  from  the  copies,  and  each  copy  from  the  other  one.  Hiding  the  secret  information 
involves  on  the  one  hand  hiding  the  location  (or  the  reference)  of  the  embedded  information  and 
on  the  other  hand  spreading  the  hidden  information. 

Digital  watermarking  techniques 

On  the  expense  of  less  embedded  information  into  the  cover  text  and  using  smarter  methods, 
even  if  the  communication  has  already  been  detected  and  the  algorithmic  principle  of  the  embedding 
became  public,  a  digital  watermark  can  permanently  reside  in  the  host  data,  able  to  resist  against  hostile 
attacks,  but  unlike  encryption,  fragile  watermarking  in  itself  does  not  resist  access  to  the  data. 

Robust  digital  watermarks  are  difficult  to  remove,  impair  from  the  cover  text,  but 
fragile  watermarks  are  relatively  easy  to  remove,  impair,  destroy  from  the  cover  text. 

Invisible  watermarks 

At  least  three  invisible  marking  techniques  are  applicable  for  formatted  black  and  white  text  printing; 

By  slightly  changing 

interline  spacing  (  Line-shift  coding  ), 
intercharacter  spacing  (  Word-shift  coding  ), 

character  font  features  (  Character  coding  )  a  publisher  can  identify  each  document  copy. 
Because  of  underlying  assumptions,  line-shift  decoding  does  not  require  the  original  unmarked  copy. 
Although  the  marks  robust  enough  to  survive  consecutive  (ten  generations)  photocopying  (see  Ref.  1  ), 
theoretically  removable,  corruptable.  The  marks  are  fragile  digital  watermarks. 

Problems  :  Any  black  and  white  marks  in  a  formatted  black  and  white  textpage,  layed  out  by  any 
technique  can  always  be  removed  by  simply  retyping,  or  by  means  of  high  resolution  scanners  and  optical 
character  recognition  (OCR/ICR)  and  reprinting  the  text  using  a  new  character  font  and  layout  format. 

Visible  watermarks 

In  offices  there  has  always  been  a  requirement  to  register  copies  of  documents.  ID  barcode  or  serial 
numbers  identified  each  copy  (and  pages  of  the  respective  copy)  on  the  margin.  By  means  of  security 
printing  scrambled  barcode  can  be  made  in  printing  houses. 

When  watermarks  generated,  they  should  be  innumerable  (distinguishable  from  each  other). 
Because  of  tracing  back  pirated  copies,  in  fingerprinting  applications  it  is  important  to  identify  the 
recipient  of  each  individual  distributed  copy  in  the  watermarks  respectively.  The  identifier  of  the  sender, 
the  event  (when  and  where)  identifying  attributes,  and  a  document  specific  message  digest  are  useful  as 
well.  In  order  to  aviod  taking  a  valid  mark  from  one  copy  and  pasting  it  onto  another  one,  the  sender  signs 
the  mark  with  a  cryptographic  key.  Digital  signature  ensures,  that  the  electronic  document  has  not  been 
altered. 


In  order  to  ensure  security  against  hostile  attacks  (data  manipulation),  erasure  of  the  watermark, 
or  unauthorized  access  of  the  watermark  content,  cryptographic  keys  are  very  useful. 

-  Steganograpy  in  combination  with  a  symmetric(secret)  key  -  that  is  secret  key  watermarking. 

-  Steganograpy  in  combination  with  an  asymmetric(public)  key  -  that  is  public  key  watermarking. 

Public  key  watermarking 

A  watermark  is  only  robust  as  long  as  it  is  cannot  be  read  by  everyone.  Public  watermarks 
(where  the  key  is  public),  are  vulnerable  to  attacks  unless  each  receiver  uses  a  different  key  (but  this  is 
difficult  in  practice).  Scrambled  images  can  be  descrambled  by  means  of  an  optical  grid  or  lens.  A 
multilevel  authentication  system  was  proposed  (see  Ref  .  2  ),where  scrambled  images  can  be  verified  by 
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variable  (electooptical)  filters,  unique  optical  decoders.  Another  option  is  a  special  scrambling  hardware 
in  the  camera. 

Assumptions  when  copying  a  scrambled  image,  if  the  image  is  coloured  (but  not  the  text),  and 

during  printing  a  proper  data  resolution/frequency  (1200  bpi)  used, 
and  a  commercially  available  colour  photocopier  is  applied, 
than  the  embedded  mark  cannot  be  copied. 

Problems  :  But  grayscale,  or  black  and  white  scrambled  images  are  copiable. 

High  resolution  /non-commercial  colour  scanners  can  make  perfect  copies  of  the  embedded 
images  as  well. 

The  reason  why  scrambled  indicia  is  still  used  in  offset  or  intaglio  security  printing  (banknotes) 
and  recently  in  personalisation  of  personal  ID,  is  that  the  scrambling  algorithm  is  secret  (the  key 
is  in  the  hardware  in  the  camera). 


Secret  key  watermarking 

Spread-spectrum  radio  communication  is  a  symmetric  key  cryptosystem.  The  band  spread  is 
accomplished  by  a  secret  key(a  signal,  which  is  independent  of  the  data)  and  a  synchronized  by  the  key 
reception  at  the  receiver  is  used  for  despreading. 

An  example  (see  Ref.  3  )  to  that,  when  parameters  of  a  control  signal  (sequential  impulse  groups 
characteristics)  are  exploited  to  represent  autonomous  control  information  of  remote  control  for  vehicles 
or  flying  objects.  That  special  data  communication  technique  was  proposed  for  transmission  of  some 
autonomous  control  attributes  in  a  common  one  way  channel  parallel  at  the  same  time  (Patent 
No. 206418).  The  method  in  itself  is  independent  of  the  field  of  application,  circuit  solution,  or 
communication  media.  The  communication  channel  can  either  be  a  cable,  or  a  radiochannel  (with 
different  modulation  options),  either  ultrasonic,  or  infrared,  etc. 

The  modulating  signal  -  an  impulse  group  -  can  be  seen  in  Fig.  1 .  One  of  the  autonomous 
attributes  is  represented  by  the  impulse-number  in  an  impulse  group  (  7  ).  Another  information  is 
represented  by  the  time  interval  between  two  starting  pulses  of  two  consecutive  pulse  groups  (8).  The 
third  information  is  represented  by  the  time  interval  rate  of  the  existance  (  5  )  and  nonexistance  (  6  )  of  a 
certain  pulse. 

It  is  almost  impossible  to  remove  or  replace  a  watermark,  when  that  requires  the  secret  key. 
Problems  :  Attackers  rather  try  to  modify  the  watermark  content.  Or  try  to  discredit  the  authority  of  the 
watermark  by  some  ambiguity  (inversion  or  interpretation)  attack.  By  means  of  reverse  engineering  many 
watermarking  schemes  might  be  approximated. 

Fake  original  documents,  fake  watermark  data  can  be  made.  If  different  watermarks  are  embedded  in  the 
same  host  data  it  ought  to  be  still  possible  to  identify  the  first(authoritative  or  copyright)  watermark. 
Possible  solutions  :  But  also  some  methods  are  devised  to  construct  noninvertible  watermarks  so 

that  making  them  signal-dependent. 

Information-losing  marking  schemes  are  also  non-invertible,  since  inverses  cannot  be 
approximated  closely  enough. 

A  combination  of  watermarking  and  timestamping  (provided  by  a  trusted  third  party),  or  notarization,  or 
a  combination  of  watermarking,  timestamping,  cryptography,  access  control,  2D  barcode. 


4.  Conditional  logical  access  control 

2D  barcode  approach 

Assumptions  :  2D  barcode  reader  and  printer, 

and  an  organisationwide  logical  access  control  system  are  available,  and 

the  really  secret  paragraphs,  details,  or  data  of  the  document  are  to  be  printed  by 
2D  barcode  (see  Fig.  2  )  or  glyph,  and 

the  document  qualification  is  :  secret,  than  a  public  key  encryption  is  also  used, 
and 

ciphering  and  deciphering  software/hardware  is  also  available,  and 

the  rest  of  the  confidential/secret  document  is  to  be  printed  as  a  normal  text,  than 
only  the  relatively  short  secret  details  (resolutions  or  important  data  in  the  protocol  of  an 
executives’  meeting,  etc.)  ought  to  be  watched  by  executives  on  a  screen. 
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Under  the  above  assumptions  the  secret  content  of  a  photocopied/scanned/photod  document  - 
although  photocopied  -  will  be  not  corrupted  indeed,  because  though  the  confidential  details  are  in  the 
copy  (and  those  remain  copyable),  but  encryption  (a  digital  signature  or  stamp)  prevents  the  data  content 
from  unauthorized  logical  access.  The  latter  has  as  good  information  protection  performance  as  of  a 
digital  signature  over  a  digital  electronic  document  or  file. 

A  combination  of  2D  barcode  with  digital  signature  (see  Ref.  4)  and  normal  text  with  polygonal 
watermark  (see  Ref.  5  )  is  proposed.  Against  synchronisation  attacks  the  watermark  reference  points  are 
also  included  in  the  2D  barcode  and  secured  by  a  digital  signature,  whilst  the  2D  barcode  block(s)  are 
embedded  in  the  text. 
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